Detection Rule Specification Template (Sigma, ATT&CK)

Detection Rule Specification: [Detection name]

Specification for one detection managed as code: the hypothesis it tests, its MITRE ATT&CK mapping, the data sources and log fields it needs, the rule body in Sigma format, logic and thresholds, true and false positive test cases, tuning, severity, the response playbook it starts, its owner and its lifecycle state. Based on the Sigma specification v2.1.0 (documents dated 2 August 2025, release tagged 12 September 2025; public domain), including Sigma correlation rules, and MITRE ATT&CK Enterprise v20 (October 2026). Write one specification per detection and keep it in the same repository as the rule file so that review, tests and deployment happen together. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company on AWS, and an original example rule that flags a burst of discovery calls made with a long-term access key from a network the company does not own.

Document control

Approvals

Revision history

Contents

1. Summary
2. Hypothesis and threat context
3. ATT&CK mapping
4. Data sources and required fields
5. Logic and thresholds
6. Sigma rule
7. Platform query and deployment
8. Test cases
9. Tuning and known false positives
10. Severity and alert routing
11. Response
12. Ownership and lifecycle
13. Performance metrics
14. Glossary and references
15. Standard and licence note

1. Summary

2. Hypothesis and threat context

Hypothesis (Example): If an unauthorised party obtains a long-term access key for a Corvid Commerce IAM user, they will first establish what the key can reach by calling many different read-only APIs in a short time, from infrastructure the company does not operate.

Threat context (Example):

• Leaked keys in public repositories are found by automated scanners quickly after publication; the time between exposure and first use can be short, so detection must run in near real time.
• Attackers use the key from rented servers, anonymising networks or compromised hosts, not from the owner's usual network.
• The first calls typically confirm identity, list accounts, users, roles, storage buckets and compute instances, often across regions.
• Legitimate automation using long-term keys also calls read-only APIs, but from a stable set of networks and with a stable, small set of API names.

Out of scope for this rule: the same behaviour using temporary credentials from an assumed role (covered by [DET-CLD-008]) and console sessions (covered by [DET-IDP-011]).

3. ATT&CK mapping

Note on tactic tags: ATT&CK v19 split the former Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112), and v20 keeps that split. The tag appendix of the Sigma specification v2.1.0 still lists the older tactic tags. This rule uses only the discovery tactic tag and technique tags, which are unaffected. For rules that observe evasion behaviour, record the v20 tactic in this table even when the Sigma file carries the older tag.

4. Data sources and required fields

Field names follow the provider's log record format. If your pipeline renames fields (for example to a common schema), add a Sigma processing pipeline that maps the names, and test it (section 8).

5. Logic and thresholds

The detection has two parts:

1. Base rule (low level, not alerted on its own): one event where a long-term IAM user key calls a read-only API (List, Describe or Get prefix) from a source address outside the known network register, excluding calls that the provider makes on the user's behalf.
2. Correlation rule (alerted): for one access key, the number of distinct API names seen by the base rule within 10 minutes is 15 or more.

Threshold derivation (Example):

Why distinct API names and not event count: automation that pages through results produces many events with the same API name. A distinct count separates "many calls to one API" (automation) from "a few calls to many APIs" (enumeration).

Known blind spots:

• An attacker who calls fewer than 15 distinct APIs, or spreads calls over more than 10 minutes, is not detected by this rule. Hunt for slow enumeration periodically (Threat Hunting Plan, security/threat-hunting-plan).
• Calls from a network listed in the register (for example through a compromised corporate host) are filtered out by design.

6. Sigma rule

The rule below is an original example written for this template. The two documents live in one file separated by ---, as the Sigma correlation specification allows. The base rule has a name so the correlation can reference it.

title: Read-Only Cloud API Call by Long-Term Access Key From Unlisted Network
id: bdcef88a-4611-4b7d-8e6b-1cbdbd72fff1
name: det_cld_007_base
status: stable
description: >
  A long-term IAM user access key made a read-only API call from a source
  address that is not in the organisation's known network register.
  Low value alone; used by the correlation rule det_cld_007.
references:
  - https://attack.mitre.org/techniques/T1580/
author: Corvid Commerce Detection Engineering (Example)
date: 2026-09-20
modified: 2026-10-24
tags:
  - attack.discovery
  - attack.t1087.004
  - attack.t1580
  - attack.t1619
  - attack.t1526
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_identity:
    userIdentity.type: IAMUser
    userIdentity.accessKeyId|startswith: AKIA
  selection_readonly:
    eventName|startswith:
      - List
      - Describe
      - Get
  filter_known_networks:
    sourceIPAddress|cidr:
      - 198.51.100.0/24
      - 203.0.113.0/25
  filter_provider_on_behalf:
    sourceIPAddress|endswith: .amazonaws.com
  condition: all of selection_* and not 1 of filter_*
falsepositives:
  - Automation using a long-term key from a network missing from the register
  - Administrators using a personal key while travelling
level: low
---
title: Discovery Burst by Long-Term Access Key From Unlisted Network
id: 698fa8bf-e676-496e-8859-8b9ff5d82d15
name: det_cld_007
status: stable
description: >
  One long-term access key called 15 or more distinct read-only APIs
  within 10 minutes from unlisted networks, consistent with enumeration
  after credential theft.
author: Corvid Commerce Detection Engineering (Example)
date: 2026-09-20
modified: 2026-10-24
correlation:
  type: value_count
  rules:
    - det_cld_007_base
  group-by:
    - userIdentity.accessKeyId
  timespan: 10m
  condition:
    field: eventName
    gte: 15
falsepositives:
  - New inventory or backup tool rolled out before its egress range was registered
level: high

Notes on the example:

• The CIDR ranges are documentation ranges (RFC 5737) standing in for the real register. In production, load the register through a processing pipeline placeholder instead of editing the rule.
• Access key ID prefixes are a provider convention (long-term keys and temporary keys use different prefixes); check the provider documentation before relying on them.
• generate is omitted, so only the correlation query is produced and the base rule does not alert on its own.
• The base rule keeps status, date, modified, falsepositives and level: low so it can also run on its own for hunting. Strictly, the correlation specification reserves meta information for the outermost correlation rule in a multi-document file; remove these fields from the base document if your tooling enforces that.
• Both documents carry status: stable because the specification is at version 1.2 (Stable). While the detection is in Test, set status: test (section 12).

7. Platform query and deployment

Deployment checklist:

• Converted query reviewed by a second engineer.
• Test cases in section 8 pass in CI against the converted query.
• Alert title includes the detection ID and links to this specification.
• Response playbook link present in the alert body.
• Suppression (section 9.3) configured.

8. Test cases

Example true positive event (one of the 41, synthetic):

{
  "eventTime": "2026-09-14T02:11:09Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",
  "awsRegion": "eu-west-1",
  "sourceIPAddress": "192.0.2.44",
  "userAgent": "[client string]",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::111122223333:user/svc-reporting",
    "accessKeyId": "AKIAEXAMPLE000000007"
  },
  "recipientAccountId": "111122223333"
}

Run the tests in three places: in CI against the converted query using stored events, in a staging SIEM index after each pipeline change, and end to end once a quarter by generating real events with a dedicated test key in a sandbox account (then deactivate the key).

9. Tuning and known false positives

9.1 Known false positives

9.2 Exceptions

Exceptions are time-boxed (at most [Example: 30 days]), approved by the SOC lead, recorded in the exception list with an expiry date and implemented as a filter in the processing pipeline, never as a change to the threshold.

9.3 Suppression

After an alert, suppress further alerts for the same key for [Example: 60 minutes] and attach new events to the open case, so one enumeration does not create a dozen cases.

10. Severity and alert routing

Escalation rule (Example): raise to P1 automatically when the same key also triggers DET-CLD-003 (audit log change) or DET-CLD-005 (key created for another user) within 60 minutes.

11. Response

• Playbook: PB-CLD-002, SOC Playbook (security/soc-playbook), starting at triage questions T1 to T3.
• Enrichment in the alert (Example): key owner from the IAM inventory, network owner and country of the source address, distinct API list, first and last event time, accounts touched, and whether the key appears in any open secret scanning alert, plus any GetSessionToken or GetFederationToken call signed with the key, because those sessions survive key deactivation (playbook step C3).
• Do not test the key or contact the source address.
• Feedback: the analyst sets the case disposition (true positive, benign true positive, false positive) so the metrics in section 13 can be computed.

12. Ownership and lifecycle

13. Performance metrics

Example (first 30 days in Test, 2026-09-20 to 2026-10-20, version 1.1): 3 alerts, 2 true positives (both from a scheduled re-run of purple team exercise PT-2026-05), 1 benign true positive (KFP-02). Precision is 2 divided by 3, or 67%. Before tuning, the 30-day backtest gave 12 alerts with the same 2 true positives, a precision of 2 divided by 12, or 17%.

14. Glossary and references

Standard and licence note

Based on the Sigma specification v2.1.0 (SigmaHQ, 2025), which is released into the public domain. The example Sigma rules in this template are original and are not taken from the SigmaHQ rule repository, whose rules are licensed under the Detection Rule License (DRL) 1.1; if you add a SigmaHQ rule, keep its author, source URL and licence as DRL 1.1 requires. MITRE ATT&CK technique and tactic names and IDs are used under the ATT&CK terms of use: The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation." MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. AWS, AWS CloudTrail and other product names are trademarks of their owners; this template is not affiliated with or endorsed by them. Check the current Sigma specification and ATT&CK release before use. Original text written for this collection. Template licence: MIT.