Resources · 29

Make security event logs ready for detection

Choose events, protect records, correlate systems and rehearse the response.

Updated 27 October 2026 · 15 min

What this guide helps achieve

Define events
Protect records
Correlate signals
Test detection

Quick check

Which systems support critical journeys?
Can clocks and identifiers reconstruct a timeline?
Who can read or alter records?
What scenario triggers an alert?
Does someone know what to do next?

Step-by-step method

01
Choose sources
Start from services and threat scenarios: sign-in, privilege change, data access, API, network and infrastructure. Define required events and their owners.
Deliverable: source-level logging policy.
02
Normalize context
Specify clocks, time zones, request identifiers, actor, outcome and originating system. Keep unnecessary secrets and personal data out of messages.
Deliverable: event schema and minimization rules.
03
Centralize and protect
Test transfer, availability, permissions, retention and tamper detection. A compromised system should not silently erase the only useful evidence.
Deliverable: transfer and integrity check.
04
Correlate a scenario
Rehearse a suspicious sign-in followed by an API call or sensitive change. Verify that events align by time and identifier.
Deliverable: reconstructed timeline and gap list.
05
Tune detection
Write a rule with condition, threshold, exceptions, owner and priority. Measure false positives and missed events using authorized scenarios.
Deliverable: tested rule and validation cases.
06
Rehearse response
Route an alert to the responsible person, open an investigation, preserve evidence and verify closure. Improve schema or rule after the exercise.
Deliverable: dated exercise and follow-up actions.

Understand · try · decide

From a received log to a verified response

A recorded event is not yet a handled alert. Separate production, collection, correlation, alerting and acknowledgement. Arrival delay and clock quality affect what an analyst can reconstruct; volume alone does not establish detection capability.

Retain event time separately from receipt time. Specify source, type, outcome and useful correlation identifier. Comparing two clocks requires known synchronisation: a negative or inconsistent delay calls for a check rather than silently correcting the timeline.

Security data should remain proportionate to its purpose. Avoid copying passwords, access tokens, keys and complete request bodies into logs. Test log access, integrity and collector failure too. The scenario should reach an accountable person and a recorded decision.

Observed behaviour → Collected event → Generated alert → Verified response — **From logs to verified detection** — Authorised exercise: a test login produces a log but no alert. Collection works; detection is not yet demonstrated. Do not mark an ATT&CK technique as covered before checking the whole chain. MITRE ATT&CK

Reference points and evidence to retain

Reference point	What you can conclude	Evidence to retain
Event	An action and its outcome are observed; an isolated anomaly does not establish an incident.	Source, time, type, outcome and minimal context.
Collection	The log has arrived; late arrival can affect real-time correlation.	Receipt time, clocks, losses and delays.
Detection	A rule connects events through an explicit scenario.	Rule version, identifiers, window and test evidence.
Response	A person qualifies the alert and acts or dismisses it with reasons.	Owner, acknowledgement times and decision.

From observation to decision

Produce and protect
Receive and check
Correlate and alert
Qualify and respond

One timeline, two reading orders

Fictional exercise on 15 October 2026, in UTC. Source and collector clocks are assumed synchronised. Rows follow event time; A1 and A2 concern fictional account U-17, while A3 is an unrelated session.

Event sequence: 35 s09:00:00 to 09:00:35 for fictional account U-17.
Maximum delay: 120 sE2 received at 09:02:20 for an event at 09:00:20.
Acknowledgement: 30 sAlert at 09:02:25, analyst at 09:02:55 in this exercise.

Fictional events: source time and receipt time
Event / interaction	Event time UTC	Receipt UTC	Delay
E1 — Failed sign-in / A1 / U-17	2026-10-15 09:00:00Z	2026-10-15 09:00:02Z	2 s
E2 — Failed sign-in / A2 / U-17	2026-10-15 09:00:20Z	2026-10-15 09:02:20Z	120 s
E3 — Successful sign-in / A2 / U-17	2026-10-15 09:00:35Z	2026-10-15 09:00:36Z	1 s
E4 — Session end / A3 / U-42	2026-10-15 09:00:40Z	2026-10-15 09:00:41Z	1 s

Receipt order: E1, E3, E4, E2. A 60-second window based only on arrival can miss E1–E2–E3; test the lateness policy rather than presume its behaviour.

Break down the exercise delay
Stage	Interval	Duration	Interpretation
Late E2 log arrival	09:00:20 → 09:02:20	120 s	Collection delay under the synchronised-clock assumption.
Sequence end → alert	09:00:35 → 09:02:25	110 s	Includes waiting for the late log and processing, rather than only the rule engine.
Alert → acknowledgement	09:02:25 → 09:02:55	30 s	Acknowledgement time, not resolution time.
First event → acknowledgement	09:00:00 → 09:02:55	175 s	End-to-end delay for this exercise, not a production average.

The rule is assumed to accept the late log and emit an alert at 09:02:25. These times describe a fictional result to reproduce rather than impose a universal deadline.

Event and receipt: see the delay

Common scale from 0 to 150 seconds after 09:00:00 UTC. Light circle: event; gold square: receipt; segment: delay. The table contains the same values.

E10 s → 2 s (+2 s)
E220 s → 140 s (+120 s)
E335 s → 36 s (+1 s)
E440 s → 41 s (+1 s)

Does a correlation identifier join every sign-in for one account?

No. A1 and A2 are separate interactions for the same fictional account. An account-level rule needs the appropriate identity; an interaction identifier joins events within that interaction.

Do 175 seconds establish resolution time?

No. In this exercise they span first event to acknowledgement. Qualification, containment and resolution are later stages to measure separately.

Checks before concluding

Replay E1–E2–E3 with E2 late, missing and duplicated; retain each variant’s result.
Test clock disagreement without changing original logs.
Check for the absence of secrets and limit the view to useful fields.
Connect the alert to a person and then a qualification; measure each delay with its endpoints.

Decision: accept the scenario when collection, correlation and acknowledgement have been observed, then document tolerated delays, missing events, owner and limits.

Change an assumption

A received event does not prove an actionable alert

In this fictional exercise, a test login attempt must produce an alert and a response. Every time uses the same reference clock.

Event
Action at 10:00:00; original timestamp retained.
Receipt
Log received at 10:00:40: a 40-second collection delay.
Response
Check alert triggering, recipient and acknowledgement separately.

Reading exercise: the variations describe fictional situations.

What if the dashboard shows only receipt time?

New evidence: The delay between action and collection becomes invisible.
What changes: Retain both timestamps and clock synchronisation information. An event received at 10:00:40 did not necessarily occur at that time.

What if the rule works but nobody responds?

New evidence: The alert appears without an acknowledgement in the tested scenario.
What changes: The test demonstrates detection, not operational response. Exercise routing, backup coverage and escalation before calling the complete chain verified.

Management indicators

Indicator	What it measures	First action
Coverage	Critical sources with expected events	Add missing sources
Delay	Time from action to searchable record	Repair transfer
Correlation	Scenarios reconstructed end to end	Add context or identifiers
Response	Tested alerts with owner and action	Fix rule or on-call path

Common pitfalls

Collecting everything without prioritizing scenarios
Logging secrets or sensitive data in clear text
Centralizing without integrity and permission checks
Adding alerts without a handling procedure

Frequently asked questions

Do more logs always mean better detection?

No. Quality, context and response capacity matter alongside volume.

Why synchronize clocks?

An inconsistent timeline makes correlation and incident decisions less reliable.

When is a rule ready?

When an authorized scenario yields the expected signal and the owner can triage it.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
OASIS · STIX 2.1 Describe threat intelligence through structured objects and relationships.	STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation.	Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period. Explore the method →	A syntactically valid object can still be stale, misattributed or weakly supported.
MITRE ATT&CK Connect observations with adversary tactics and techniques.	ATT&CK is a knowledge base grounded in observations. Its domains include Enterprise, Mobile and ICS.	Connect a technique with a trace and detection hypothesis. Distinguish having a log source from actually testing detection. Explore the method →	A shared technique cannot establish actor attribution. Technique coverage counts do not fully measure security.

STIX indicators and TLP sharing

Cyber threat intelligence: from an indicator to a defensible detection

A threat intelligence feed may deliver a domain, a detection pattern and a confidence assessment. A SOC still needs its provenance, useful time window, telemetry capable of recognising it and a retirement procedure. This reference helps prepare that decision and explain its limits to the recipient.

The properties and objects described here refer to the OASIS STIX 2.1 Standard dated 10 June 2021. Deployment checks, review deadlines and case decisions are local editorial proposals. This page is neither a STIX validator, a blocking rule nor an assessment of a real feed.

Version note: at review time the OASIS latest-stage URL points to a document dated 2 April 2025 titled STIX 2.1 Errata 01, incorporating Draft 01. Its draft errata status is retained in the citation; it is not presented as a newly approved final version. Agree marking encodings with the recipient and check the edition actually used.

Local indicator lifecycle and a separate sharing check

Four steps: preserve source and version; qualify validity and context; test detection against logs; review and propagate retirement. TLP scope is checked at every disclosure, independently of confidence.

12 reading checks before importing an indicator

12 reading checks before importing an indicator
STIX 2.1 property	What it tells you	Operational check to record
id / modified	A versioned object retains its id; modified identifies its version.	Compare received versions before overwriting local state. A later delivery can contain an older version.
created_by_ref	Optional reference to the creator’s Identity; when absent, this property leaves the source undefined.	Also preserve collection provenance. A TAXII relay is not necessarily the intelligence creator.
created / modified	Object creation and version modification times; modified is at least equal to created.	Do not treat them as first and last observed activity times.
pattern / pattern_type	Both the pattern and its language are required; a STIX pattern describes a condition to recognise.	Check language, version, parser and available telemetry fields before translating it into a SIEM rule.
valid_from	Required start of the Indicator’s validity window.	A future start calls for holding or review; it does not establish current activity.
valid_until	Optional end, strictly later than valid_from when present. At this time the indicator should no longer be considered valid.	Without an end the standard sets no upper time bound. Still assign a local review date without inventing a producer expiry.
revoked	Permanent withdrawal by the creator. No future version of the same id may be created after revocation.	Propagate withdrawal to derived uses and preserve the record. Expiry or a local false positive does not automatically mean revoked=true.
confidence	Optional integer from 0 to 100 expressing the creator’s confidence in data correctness; absence means unspecified.	Preserve the producer’s method. Do not turn 60 into a 60% probability of compromise, or absence into zero.
external_references	Links, descriptions or identifiers referring to external information.	Check origin and access to cited evidence. Multiple copies of one report are not independent sources.
object_marking_refs	References to marking-definition objects applying to the object.	Resolve references and preserve restrictions in copies, tickets and summaries.
granular_markings	Markings or languages applying to specific parts of an object.	Check the relevant fields before quoting an excerpt; a title’s marking does not establish the pattern’s marking.
description / indicator_types	Narrative context and categories help interpretation; these properties are optional.	Explain the behaviour sought, prerequisites, possible legitimate uses and person responsible for review.

Four objects answering four different questions

Four objects answering four different questions
Object	Question it answers	Analytical limit
Indicator	What pattern could recognise suspicious activity?	A usable pattern is not evidence that the activity occurred in your environment.
Observed Data	What data was observed, and during which window?	Observed facts alone do not establish attribution or malicious intent.
Sighting	Which intelligence entity does the reporter believe they saw?	The assertion may reference Observed Data. Sighting count and number_observed measure different things.
Relationship	What link is asserted between two objects?	An indicates or based-on link has a specific meaning. A dense graph does not prove attribution.

Read a fictional object without turning it into an alert

A standalone training example written for this page; no real threat intelligence. RFC 2606 reserves .example for documentation. Dates and confidence 60 are fictional. Creator and marking are deliberately absent: this establishes neither a verified source nor permission to publish. This is neither a complete bundle nor an OASIS-tool compliance validation.

{
    "type": "indicator",
    "spec_version": "2.1",
    "id": "indicator--643d2844-11ca-4f63-8d5d-e5d938db1854",
    "created": "2026-10-22T09:00:00.000Z",
    "modified": "2026-10-22T09:00:00.000Z",
    "lang": "en",
    "name": "Fictional training indicator",
    "description": "Documentation only. Never deploy this example as a detection or blocking rule.",
    "pattern": "[domain-name:value = 'training-beacon.example']",
    "pattern_type": "stix",
    "pattern_version": "2.1",
    "valid_from": "2026-10-22T09:00:00Z",
    "valid_until": "2026-10-23T09:00:00Z",
    "confidence": 60
}

At 10:00 UTC on 22 October 2026, the time falls inside the stated window. This establishes neither a log match nor maliciousness. Deriving a detection would still require the producer, context, restrictions, telemetry, exceptions and retirement owner.

Eight fictional qualification and sharing cases

Each case isolates one difficulty. Suggested decisions belong to a local working method, rather than automatic verdicts from STIX syntax alone. The filter only hides examples already in the page; it sends no data.

Validity starts tomorrow

The pattern arrives today; valid_from is tomorrow.

Retain the object for review and schedule assessment at the appropriate time; receipt alone does not justify immediate blocking.

Keep receipt time, evaluation time and object version. Historical investigation has a different purpose.

Validity end reached

At 09:00 UTC, valid_until is reached; a derived rule remains active.

Remove the object from active candidates or trigger the planned retirement process, then check derived rules.

Retain history and the withdrawal rationale. The deadline does not prove past events were benign.

Revocation received after import

A new version of the same id contains revoked=true.

Propagate withdrawal to dependent uses and verify each consumer’s state.

Keep the received version and propagation record; do not reactivate the object from an older copy.

Confidence unspecified

The feed provides no confidence; an interface proposes displaying 0.

Display unspecified, request provenance and describe available corroboration.

An internal scoring convention may exist, but must be named and kept separate from the producer’s value.

Shared domain and DNS log

A cited domain appears in a DNS log; it also hosts legitimate uses.

Inspect the exact name, time, host and related events; prepare a focused search before broad action.

DNS resolution demonstrates neither download, execution nor compromise. Plan exceptions and rollback.

Sighting count=0

A producer publishes a Sighting with count=0.

Read this as a non-observation statement in its context, then ask about window and coverage.

Zero does not measure worldwide absence of the threat. It does not replace checks of your own sensors.

Client and AMBER+STRICT

A recipient wants to forward a TLP:AMBER+STRICT note to a client.

The restriction limits sharing to the organisation on a need-to-know basis; obtain explicit source permission to widen it.

Do not mistakenly apply the client-sharing scope associated with AMBER without STRICT.

GREEN message to a public channel

A TLP:GREEN note is proposed for a public article.

Keep the note inside the permitted community; ask the source for permission to share more widely.

A publicly accessible web page exceeds GREEN’s scope. Source attribution does not lift the restriction.

TLP 2.0: recipients, need to know and restrictions

FIRST defines four labels; AMBER+STRICT restricts AMBER rather than adding a fifth colour. Labels remain unchanged across languages. This matrix summarises TLP scope and does not replace additional source restrictions or applicable document rules.

TLP 2.0: recipients, need to know and restrictions
Marking	Sharing scope	Check
TLP:RED	Individual recipients only; no further disclosure.	A colleague’s membership of the same organisation does not authorise forwarding.
TLP:AMBER	Organisation and clients on a need-to-know basis to protect them and prevent further harm.	Check that the recipient needs the information and no additional restriction narrows this scope.
TLP:AMBER+STRICT	Organisation only, on a need-to-know basis.	Clients are not included by default under this restriction.
TLP:GREEN	The relevant community; no publicly accessible channels.	When the community is undefined, FIRST assumes the cybersecurity/defence community.
TLP:CLEAR	No TLP disclosure limit, subject in particular to copyright rules.	Preserve origin, separate restrictions and applicable public-release procedures.

TLP describes a sharing scope; it certifies neither accuracy, official classification nor a usage licence. Encryption and retention rules need separate definition. Obtain explicit source permission before widening the received scope.

Interoperability check: predefined TLP markings in the 2021 STIX 2.1 edition include TLP:WHITE. FIRST’s TLP 2.0 vocabulary uses TLP:CLEAR and specifies AMBER+STRICT. Do not invent a tlp=clear encoding or silently rename historical markings: document the version and exchange profile actually supported by the tools.

Six elements to hand over with the decision

Object identifier and version, declared producer and collection provenance.
UTC timestamps: receipt, validity window and a clearly separate local review date.
Detection hypothesis, required logs, fields used and known sensor coverage.
Search results and limits: absence, match, ambiguity or a justified false positive.
Recipients, markings, additional restrictions and permission to widen scope where applicable.
Owner, derived rule or ticket, decision, planned retirement and propagation verification.

References and verification scope

OASIS · STIX 2.1 · OASIS Standard · 2021-06-10
§3.2, §3.6, §4.7, §4.14, §5.2, §7.2
OASIS · STIX 2.1 Errata 01 · Draft 01 · 2025-04-02 · OASIS Standard incorporating Draft 01 of Errata 01
Status / Citation format · draft status identified separately
FIRST · Traffic Light Protocol 2.0 · TLP 2.0 · 2022-08
§1, §2, §3 · TLP:AMBER+STRICT
IETF · RFC 2606 · BCP 32 · 1999-06
§2 · .example reserved for documentation

Sources checked on 2026-10-22

Syslog codes and collection evidence

Syslog priority combines a message family (facility) and a declared severity. It helps interpret a log stream but measures neither attack likelihood nor business incident urgency. Check what the sender encodes and what the collector preserves.

32 official values: 24 facilities and 8 severities. IANA registry updated 26 April 2016, consulted 23 October 2026. Cases and acceptance questions below are original CIE editorial examples.

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

How do you calculate and decode syslog priority?

PRI = facility × 8 + severity. Reverse it with facility = integer quotient of PRI / 8 and severity = remainder of PRI / 8. The 192 combinations span 0–191. The field uses angle brackets and no leading zero except <0>. Example: 20 × 8 + 5 = 165, written <165>.

PRI is not a global danger ranking: <184> combines local7 and Emergency while <7> combines kernel and Debug. Interpret severity in the source context. A declared value or hostname does not authenticate a message.

IETF · R. Gerhards · RFC 5424 · The Syslog Protocol · March 2009 · §6.2.1 PRI · §6 format · §8 security

Calculate PRI

Choose two codes or enter only a PRI integer, with or without angle brackets. Accepted examples: 0, 165, <165>, <191>. Spaces, signs, decimals, leading zeros and complete messages are rejected. Calculation stays on this page; it does not connect to your equipment.

Official facility and severity tables

The registry’s English labels are preserved. A local0–local7 code does not identify the product or service that emitted it: your organisation must document its operational meaning.

24 facilities · codes 0–23

24 facilities · codes 0–23
Code	Official IANA label	Registry note
0	kernel messages
1	user-level messages
2	mail system
3	system daemons
4	security/authorization messages	Codes 4, 10, 13 and 14 have similar security, authorization, audit and alert uses across operating systems.
5	messages generated internally by syslogd
6	line printer subsystem
7	network news subsystem
8	UUCP subsystem
9	clock daemon	Both codes 9 and 15 are used for clock or scheduled-job messages across operating systems.
10	security/authorization messages	Codes 4, 10, 13 and 14 have similar security, authorization, audit and alert uses across operating systems.
11	FTP daemon
12	NTP subsystem
13	log audit	Codes 4, 10, 13 and 14 have similar security, authorization, audit and alert uses across operating systems.
14	log alert	Codes 4, 10, 13 and 14 have similar security, authorization, audit and alert uses across operating systems.
15	clock daemon	Both codes 9 and 15 are used for clock or scheduled-job messages across operating systems.
16	local use 0 (local0)
17	local use 1 (local1)
18	local use 2 (local2)
19	local use 3 (local3)
20	local use 4 (local4)
21	local use 5 (local5)
22	local use 6 (local6)
23	local use 7 (local7)

8 severities · codes 0–7

8 severities · codes 0–7
Code	Official IANA label	Registry note
0	Emergency: system is unusable
1	Alert: action must be taken immediately
2	Critical: critical conditions
3	Error: error conditions
4	Warning: warning conditions
5	Notice: normal but significant condition
6	Informational: informational messages
7	Debug: debug-level messages

IANA · Licensing Terms · Protocol Registries CC0 1.0 · Revised 2021-11-10 · original CIE commentary identified separately

Read a message before building a rule

Fictional example, containing no production data:

<165>1 2026-10-23T09:14:00Z gateway.example.net app 742 EVT42 [meta sequenceId="12"] Cache refreshed

Read a message before building a rule
Element	Reading this example	Acceptance consideration
<165>	facility 20, severity 5	Document the sender’s convention.
1	Format version	Distinguish the received format from collector-added labels.
TIMESTAMP	Source timestamp in UTC	Check reception time and clock drift as well.
HOSTNAME / APP-NAME	gateway.example.net / app	Connect the declaration to your equipment inventory.
PROCID / MSGID	742 / EVT42	Do not treat a process number as a universal identifier.
STRUCTURED-DATA	meta with sequenceId 12	Preserve names and parameters without flattening distinct identifiers.
MSG	Cache refreshed	Do not log secrets to enrich an event.

A NILVALUE hyphen marks unavailable information in fields that allow it; it does not mean zero. Decoding PRI alone validates neither the rest of a message, its timestamp nor its transport.

Eight explained calculations · fictional situations

Eight explained calculations · fictional situations
Facility / severity	Calculation and PRI	Interpretation and limit
0 / 0	0 × 8 + 0 = 0 · <0>	Kernel / Emergency: encoding an outage does not establish its cause.
1 / 5	1 × 8 + 5 = 13 · <13>	User-level / Notice: a notable condition may still be normal.
4 / 2	4 × 8 + 2 = 34 · <34>	Security / Critical: qualify the rule and asset before escalating.
10 / 5	10 × 8 + 5 = 85 · <85>	Security / Notice: one family can carry a different severity.
13 / 6	13 × 8 + 6 = 110 · <110>	Audit / Informational: an informative event can be decisive in an investigation.
20 / 5	20 × 8 + 5 = 165 · <165>	Local4 / Notice: document the local convention; no universal product meaning.
23 / 0	23 × 8 + 0 = 184 · <184>	Local7 / Emergency: high PRI, most severe level on this severity scale.
23 / 7	23 × 8 + 7 = 191 · <191>	Local7 / Debug: same facility, eighth level, not evidence of harmlessness.

Collection acceptance: what evidence should you request?

Correct decoding does not establish useful detection. The joint guidance published by ASD ACSC and partners in 2024 addresses policy, centralisation, protected storage and detection strategy. This CIE acceptance proposal should be adapted to the service.

Collection acceptance: what evidence should you request?
CIE check	Practical exercise	Expected evidence
Source coverage	Trigger an identified test event on a critical source.	Find source, collector, index and owner; record absent sources.
Severity convention	Compare a known event before and after normalisation.	Preserve raw code, normalised value and versioned conversion rule.
Identity and correlation	Follow a fictional sign-in and subsequent application action.	Connect useful identifiers without logging tokens, passwords or sensitive content.
Time and delay	Compare source time, reception and search availability.	Separate clock drift, transport delay and indexing delay.
Loss and recovery	Interrupt an authorised test stream and restore it.	Observe gaps, queues, possible duplicates and missing-stream alerts.
Truncation and parsing	Feed a long message and malformed event into the test pipeline.	Record received size, lost fields or rejection; do not equate rejection with inactivity.
Path protection	Review transfer, access and retention with the owners.	Identify every hop, permissions and the protection mechanisms actually configured.
Detection and response	Trigger a rule in an authorised scenario and follow handling.	Connect event, alert, qualification, decision and observed result.

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Set retention, scope and thresholds according to investigation needs and the service’s applicable constraints. This table defines neither a universal retention period nor SIEM certification. A format check cannot replace an end-to-end exercise.

Value provenance and consulted edition

IANA · 32 codes · registry 2016-04-26 · reviewed 2026-10-23 · CC0 1.0

IANA XML SHA-256: 10eb91ad6e29dc6fdebe5320cc0b2711ce840c1ed7a6d2c33c4bc716423b4ec6

RFC 5424 TXT SHA-256: 24d91f90a05d2536730ada929c296f45ae9cd72226e22b6775ad8c04cae37a53

Commentary, cases and acceptance proposal: Cyber Intelligence Embassy. IANA labels are reproduced for reference.

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.