Notifications
Clear all
Topic starter
02/08/2026 11:42 am
TL;DR: Security logs only support threat detection, forensics, and compliance when teams centralize, baseline, correlate, and automate across fragmented formats, according to Panther's analysis of log types and analysis workflows. For IAM and NHI programmes, the key issue is not log volume alone but whether identity, action, and outcome are captured well enough to reveal abuse before containment slips.
NHIMG editorial — based on content published by Panther: What Are Security Logs? Types, Examples, and Analysis
By the numbers:
- Only 20% of security events were actually being logged before they centralized.
- Organizations that detect threats internally have a 11-day median dwell time, versus 26 days when an external entity notifies them.
- Large enterprises use an average of 45 cybersecurity tools, each emitting logs in a different format.
Questions worth separating out
Q: What breaks when security teams do not centralize logs before building detections?
A: Detections become incomplete because teams can only query the sources they actually receive.
Q: Why do service accounts create different logging requirements from human users?
A: Service accounts usually operate at machine speed, with stable patterns, limited interactivity, and frequent API or role-assumption activity.
Q: How do teams know whether identity-based detection is working?
A: Look for detections that correlate identity, behaviour, and privilege changes across environments, not just isolated alerts.
Practitioner guidance
- Map identity-critical log sources first Inventory every source that can evidence authentication, role assumption, API use, and privilege change, then confirm it is actually forwarding data into the central pipeline.
- Normalize identity fields before writing detections Define a common schema for actor, source, action, outcome, and target so CloudTrail, Windows Event Logs, Linux auth logs, and SaaS audit records can be correlated consistently.
- Build service account baselines from real workload behaviour Establish expected ranges for API call volume, role assumption frequency, source location, and time-of-day access for each NHI.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Field-by-field log examples across CloudTrail, Windows Event Logs, Linux auth logs, and application telemetry
- The exact detection pivots Panther recommends for authentication, endpoint, and cloud control-plane analysis
- Practical guidance on baselining, correlation, and detection-as-code implementation in the SOC
- Cost and staffing considerations for SIEM operations at cloud scale
👉 Read Panther's guide to security log types, analysis, and detection →
Security logs and identity signals: what teams miss in practice?
Explore further
02/08/2026 12:54 pm
Security logging is now an identity governance problem, not just a SOC function. The article shows that logs only become useful when identity, action, and outcome can be tied together across cloud, endpoint, and application sources. That is especially true for NHIs, where service accounts and tokens often generate the first machine-readable evidence of abuse. The practitioner takeaway is that logging strategy must be aligned to identity governance outcomes, not only to detection coverage.
A question worth separating out:
Q: Which frameworks should teams use to govern identity-aware logging and detection?
A: NIST CSF, NIST SP 800-53 Rev 5 Security and Privacy Controls, and MITRE ATT&CK all align well with identity-aware logging because they require dependable source data, auditability, and technique mapping. Teams should use them to define what must be logged, how long it must be retained, and how detections prove identity abuse.
👉 Read our full editorial: Security logs are only useful when identity signals are centralised
