Skip to content

Add log timestamp trust evidence gates #1456

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jddark62 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add log timestamp trust evidence gates #1456

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 55 additions & 5 deletions skills/secops/log-analysis/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ phase: [operate]
frameworks: [MITRE-ATT&CK-v16, NIST-SP-800-92]
difficulty: intermediate
time_estimate: "20-40min"
version: "1.0.0"
version: "1.0.1"
author: unitoneai
license: MIT
allowed-tools: Read, Grep, Glob
Expand Down Expand Up @@ -59,11 +59,44 @@ Before beginning analysis, gather or confirm:
- [ ] **Known-good context:** What is expected/normal for this environment? (Authorized admin accounts, expected service accounts, normal working hours, approved applications.)
- [ ] **Related alerts or incidents:** Are there existing alerts, tickets, or incident reports associated with this investigation?
- [ ] **SIEM access:** Which SIEM platform contains the logs? (Determines query language and table names.)
- [ ] **Timestamp trust basis:** For each source, identify event time, ingestion/index time, parser-selected timestamp field, source timezone, clock synchronization evidence, observed skew, and confidence before cross-source correlation.

---

## 3. Process

### Step 0: Timestamp Normalization and Clock-Skew Gate

Before reconstructing a timeline, prove that timestamps from different sources are comparable. Do not present a definitive sequence until the analysis records the timestamp basis for each source.

**Required timestamp evidence:**

| Evidence Field | Required Detail | Why It Matters |
|----------------|-----------------|----------------|
| Event Time | Native timestamp from the original event record (`eventTime`, Windows `TimeCreated`, Sysmon `UtcTime`, syslog timestamp, application timestamp) | Establishes when the source says the activity happened |
| Ingestion / Index Time | Collector receive time, SIEM `_indextime`, `event.ingested`, or queue receipt time | Detects late-arriving logs and ordering errors caused by buffering |
| Parser Timestamp Field | Field the SIEM/search platform used as canonical time (`_time`, `@timestamp`, normalized timestamp, custom mapping) | Prevents parser mistakes from silently changing event order |
| Source Time Zone | UTC offset, local timezone, host locale, or "unknown" | Required for Windows local time, Linux syslog without timezone, and SaaS/cloud sources |
| Clock Sync / Skew Evidence | NTP/chrony/w32time status, cloud time-sync status, EDR clock telemetry, or comparison to trusted collector time | Determines whether host events can be compared to other sources |
| Confidence Decision | `High`, `Medium`, `Low`, or `Not Evaluable` with reason | Calibrates whether the timeline can support definitive findings |

**Timestamp confidence rules:**

| Condition | Timeline Confidence | Required Handling |
|-----------|---------------------|-------------------|
| Event time, timezone/UTC offset, parser field, ingestion time, and clock-sync evidence are all documented; observed skew is within the investigation tolerance | High | Use events in the definitive timeline and cite the timestamp basis |
| Minor ingestion delay or bounded clock skew is documented and does not change the event ordering | Medium | Use events with confidence notes and preserve ordering caveats |
| Timezone is inferred, year is missing, parser mapping is uncertain, or host clock skew could change event order | Low | Scope findings to lower-confidence observations; do not claim exact sequencing |
| Event time or timezone cannot be established, parser-selected time is unknown, or source clock health is unavailable for a sequence-critical host | Not Evaluable | Exclude from definitive timeline or present a separate unsequenced evidence section |

**Source-specific checks:**

- **Windows/Sysmon:** Confirm whether the exported field is UTC (`UtcTime`) or local time (`TimeCreated`), record host timezone, and compare to domain controller or collector receipt time.
- **Linux syslog/auth logs:** Add year/timezone from log source metadata or collection context; if unavailable, mark sequence-sensitive findings `Low` or `Not Evaluable`.
- **AWS CloudTrail:** Use `eventTime` for activity time, record SIEM ingestion/index delay separately, and do not assume CloudTrail events arrive in order.
- **Splunk:** Record both `_time` and `_indextime`; investigate cases where `_time` is parser-derived from the wrong field.
- **Elastic:** Record `@timestamp`, `event.ingested`, and source-specific event time if distinct; note that `@timestamp` semantics can vary by integration.

### Step 1: Log Source Taxonomy

Understand what each log source provides and which ATT&CK data sources it maps to.
Expand Down Expand Up @@ -337,7 +370,7 @@ Produce log analysis findings in this structure:
```markdown
## Security Log Analysis Report
**Date:** [YYYY-MM-DD]
**Skill:** log-analysis v1.0.0
**Skill:** log-analysis v1.0.1
**Frameworks:** MITRE ATT&CK v16, NIST SP 800-92
**Analyst:** [Name or AI-assisted]

Expand All @@ -352,6 +385,16 @@ Produce log analysis findings in this structure:
| Users | [Usernames or "all users"] |
| Log Sources | [List of log sources analyzed] |

### Timestamp Normalization and Clock-Skew Evidence
| Source | Event Time Field | Parser Time Field | Ingestion / Index Time | Source Time Zone | Clock Sync / Skew Evidence | Confidence | Handling |
|--------|------------------|-------------------|-------------------------|------------------|----------------------------|------------|----------|
| [Windows Security] | [TimeCreated] | [_time/@timestamp/etc.] | [_indextime/event.ingested/etc.] | [UTC/local/offset/unknown] | [NTP/w32time/collector delta] | [High/Medium/Low/Not Evaluable] | [Use / Caveat / Exclude] |

### Timeline Confidence Decision
| Decision | Basis | Impact on Findings |
|----------|-------|--------------------|
| [High/Medium/Low/Not Evaluable] | [Why the timestamp evidence is or is not sufficient] | [Whether findings can claim exact ordering, bounded ordering, or only unsequenced observations] |

### Findings Summary
| # | Finding | Severity | ATT&CK Technique | Log Source | Evidence |
|---|---------|----------|-------------------|------------|----------|
Expand All @@ -370,9 +413,9 @@ Produce log analysis findings in this structure:
[Interpretation of the evidence -- why is this significant or benign?]

### Timeline
| Timestamp (UTC) | Source | Event | ATT&CK Technique | Assessment |
|-----------------|--------|-------|-------------------|------------|
| [HH:MM:SS] | [Source] | [Description] | [T-ID] | [Suspicious / Benign / Confirmed malicious] |
| Timestamp (UTC) | Source | Event | ATT&CK Technique | Timestamp Confidence | Assessment |
|-----------------|--------|-------|-------------------|----------------------|------------|
| [HH:MM:SS] | [Source] | [Description] | [T-ID] | [High/Medium/Low/Not Evaluable] | [Suspicious / Benign / Confirmed malicious] |

### Baseline Observations
[Any baseline deviations noted, with comparison to established norms]
Expand Down Expand Up @@ -451,6 +494,10 @@ A single Event ID can have very different meanings depending on the context. Eve

Attempting to identify anomalous behavior without knowing what normal behavior looks like leads to both false positives (flagging normal activity as suspicious) and false negatives (missing truly anomalous activity that blends into an unfamiliar baseline). Invest in baseline establishment for high-value log sources before relying on anomaly-based analysis.

### Pitfall 6: Building Exact Timelines from Untrusted Time Fields

Cross-source timelines are only as reliable as their timestamp basis. Windows local time, Linux syslog entries without a year/timezone, CloudTrail delivery delay, SIEM parser mistakes, and host clock skew can all invert event order. Record event time, ingestion/index time, parser-selected time, timezone, and clock-sync evidence before claiming a precise sequence. If that evidence is missing, downgrade the confidence or mark the timeline `Not Evaluable`.

---

## 8. Prompt Injection Safety Notice
Expand Down Expand Up @@ -478,3 +525,6 @@ This skill processes user-supplied content that may include raw log data, event
9. **AWS CloudTrail Event Reference** -- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html
10. **Azure Activity Log Schema** -- https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log-schema
11. **NIST SP 800-61 Rev 2 -- Incident Handling Guide** -- https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
12. **AWS CloudTrail Record Contents** -- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
13. **Splunk timestamp recognition** -- https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/9.4/configure-timestamps/configure-timestamp-recognition
14. **Elastic ECS event fields** -- https://www.elastic.co/guide/en/ecs/current/ecs-event.html
149 changes: 149 additions & 0 deletions skills/secops/log-analysis/tests/timestamp-normalization-clock-skew-edge-cases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
# Timestamp Normalization and Clock-Skew Edge Cases

These fixtures calibrate the `log-analysis` timestamp trust gate. Each case should force the skill to record event time, ingestion/index time, parser-selected timestamp field, source timezone, clock synchronization / skew evidence, and a confidence decision before reconstructing a cross-source timeline.

## Vulnerable: Windows Local Time Ambiguity

```yaml
case: windows-local-time-ambiguous
source: Windows Security Event Log export
event:
EventID: 4624
TimeCreated: "2026-06-05 01:14:22"
Computer: "workstation-17.corp.example"
TargetUserName: "svc-build"
LogonType: 10
collection:
siem_time_field: "_time"
siem_time_value: "2026-06-05T01:14:22Z"
index_time: "2026-06-05T09:17:04Z"
source_timezone: "unknown"
clock_sync_evidence: "not provided"
expected_result:
confidence: "Not Evaluable"
reason: "Windows local TimeCreated was normalized as UTC without timezone or host clock evidence."
required_handling: "Do not place this RDP logon in the definitive UTC timeline until source timezone and skew are established."
```

## Vulnerable: CloudTrail eventTime vs SIEM Ingestion Delay

```yaml
case: cloudtrail-eventtime-ingestion-delay
source: AWS CloudTrail through SIEM
event:
eventName: "AttachUserPolicy"
eventTime: "2026-06-05T12:03:19Z"
userIdentity:
type: "IAMUser"
userName: "temporary-admin"
sourceIPAddress: "198.51.100.44"
collection:
siem_time_field: "_indextime"
siem_time_value: "2026-06-05T12:48:52Z"
parser_event_time_field: "missing"
source_timezone: "UTC"
clock_sync_evidence: "AWS managed service time"
expected_result:
confidence: "Low"
reason: "SIEM used index time rather than CloudTrail eventTime; CloudTrail delivery does not guarantee order."
required_handling: "Use eventTime as activity time and document the 45 minute ingestion delay before correlating with endpoint or identity events."
```

## Vulnerable: Sysmon Host Clock Skew

```yaml
case: sysmon-host-clock-skew
source: Sysmon Event ID 1
event:
EventID: 1
UtcTime: "2026-06-05 18:22:10.112"
Image: "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
CommandLine: "powershell -enc <redacted>"
Computer: "finance-laptop-04"
collection:
collector_receive_time: "2026-06-05T18:09:51Z"
siem_time_field: "UtcTime"
source_timezone: "UTC"
clock_sync_evidence: "EDR reports host clock +12m19s ahead of collector"
expected_result:
confidence: "Medium"
reason: "Clock skew is documented and bounded, but it can alter ordering inside a narrow attack chain."
required_handling: "Apply skew correction or show a bounded time range; do not claim second-level ordering against firewall or proxy logs."
```

## Vulnerable: Linux auth.log Missing Year and Timezone

```yaml
case: linux-auth-missing-year-timezone
source: /var/log/auth.log
event:
raw: "Jun 05 23:58:03 bastion-02 sshd[2201]: Accepted publickey for deploy from 203.0.113.77 port 55112 ssh2"
collection:
file_mtime: "2026-06-06T00:03:14Z"
collector_timezone: "America/Los_Angeles"
host_timezone: "unknown"
siem_time_field: "@timestamp"
siem_time_value: "2026-06-06T06:58:03Z"
clock_sync_evidence: "not provided"
expected_result:
confidence: "Low"
reason: "Syslog line lacks year/timezone and host timezone was inferred from collector context."
required_handling: "Include the SSH event as lower-confidence evidence unless host timezone and collection year are proven."
```

## Vulnerable: Parser Mapping Mistake

```yaml
case: parser-mapped-ingestion-as-event-time
source: SaaS audit log
event:
activity: "mailbox_forwarding_rule_created"
activity_time: "2026-06-05T14:05:44Z"
received_at: "2026-06-05T16:42:03Z"
actor: "finance.user@example.com"
collection:
parser_time_field: "received_at"
canonical_timestamp: "2026-06-05T16:42:03Z"
index_time: "2026-06-05T16:42:05Z"
source_timezone: "UTC"
clock_sync_evidence: "SaaS provider signed audit export"
expected_result:
confidence: "Low"
reason: "Parser selected receipt time as canonical event time, moving the activity more than two hours later."
required_handling: "Correct the parser field or cite both activity_time and received_at before correlating with mailbox sign-in events."
```

## Benign: Complete Normalized Multi-Source Timeline

```yaml
case: complete-normalized-multi-source-timeline
sources:
windows_security:
event_time: "2026-06-05T15:01:04Z"
ingestion_time: "2026-06-05T15:01:11Z"
parser_time_field: "TimeCreated converted from UTC"
source_timezone: "UTC"
clock_sync_evidence: "w32time synchronized to dc-01; observed skew +1.2s"
cloudtrail:
event_time: "2026-06-05T15:03:48Z"
ingestion_time: "2026-06-05T15:07:29Z"
parser_time_field: "eventTime"
source_timezone: "UTC"
clock_sync_evidence: "AWS managed service time; delivery delay recorded separately"
linux_auth:
event_time: "2026-06-05T15:06:32Z"
ingestion_time: "2026-06-05T15:06:38Z"
parser_time_field: "auth.log timestamp plus host timezone metadata"
source_timezone: "UTC"
clock_sync_evidence: "chronyc tracking offset -0.8s"
elastic:
event_time: "2026-06-05T15:08:10Z"
ingestion_time: "2026-06-05T15:08:16Z"
parser_time_field: "@timestamp from source event.created"
source_timezone: "UTC"
clock_sync_evidence: "event.ingested - @timestamp = 6s"
expected_result:
confidence: "High"
reason: "Each source has event time, ingestion time, parser field, timezone, and bounded clock evidence."
required_handling: "Use the events in the definitive timeline and cite timestamp evidence in the report."
```