From Noise to Signal: Fixing SIEM with Unified Security Telemetry and Identity

Introduction

In the summer of 2023, the Storm-0558 cyberespionage group accessed email accounts belonging to US government agencies. The attackers used a stolen Microsoft signing key to forge authentication tokens. They did not need to guess passwords or run a conventional phishing campaign.

That left many account-compromise controls with little to detect. There was no trail of failed logins and no malware signature. The intrusion was discovered after a customer found unusual MailItemsAccessed events in Microsoft audit logs, prompting a wider investigation.

The incident reflects a problem familiar to Security Operations Centre (SOC) teams. They collect enormous amounts of security data, yet much of it arrives without the context needed to investigate it. A login, API call, process execution, or permission change says little by itself. Analysts still need to establish who performed the action, which device and session were involved, what access the account held, and whether the activity made sense for that identity.

Without those connections, a Security Information and Event Management (SIEM) platform becomes an expensive alert queue. Collecting more logs will not solve that problem. Security telemetry must be organised around the human and machine identities responsible for the activity.

Alert Volume Is a Poor Measure of SIEM Value

SIEM programmes are often judged by collection metrics: connected log sources, daily ingestion volume, or months of retained data. Those numbers matter for capacity and cost, but they reveal very little about whether analysts can reach sound decisions.

The investigation queue is a more honest measure.

If it contains isolated alerts with no actor, privilege, device, or session information, the SIEM is storing data rather than supporting detection. Most of the resulting noise falls into three categories:

Volume noise: The SIEM creates more alerts than the team can investigate.
Fidelity noise: A rule works as written but cannot separate an attack from legitimate activity.
Context noise: The alert may be important, but the analyst must search several systems before understanding who acted, what access was used, and what was affected.

These problems need different remedies. Lowering the number of alerts will not supply missing identity data. Adding identity data will not repair a badly designed rule. Treating all alert noise as one problem usually produces another round of tuning without addressing its cause.

Fragmented Telemetry Creates Fragile Detections

Cloud platforms, SaaS applications, endpoint products, and network appliances do not describe activity in the same way.

One product records a user, another a principal, and another a subject or account. Timestamps use different formats and time zones. Successful actions might be recorded as success, allowed, 200, or a proprietary status code. Two systems can observe the same activity and still produce records that are difficult to correlate.

Detection engineers are left maintaining vendor-specific field mappings and rule logic. These rules break easily. A minor schema change can stop a correlation from working without producing an obvious error, while analysts continue to assume the detection is active.

Poor governance adds another layer of noise. Teams introduce new rules but rarely retire old ones. Permissions change every day, while access reviews may happen quarterly. Analysts discuss recurring false positives, yet no one owns the work required to correct the rule.

Better telemetry can make correlation easier. It cannot compensate for missing ownership, weak review practices, or rules that remain enabled simply because nobody wants to remove them.

What Makes Security Telemetry Useful?

Centralised logging and unified telemetry are not the same thing. Moving raw events into a common repository may simplify storage, but it does not automatically improve an investigation.

Telemetry becomes useful when:

Different event formats are translated into consistent security concepts.
Related activity can be joined through stable identifiers.
Events carry enough context for an analyst to judge their importance.

The Open Cybersecurity Schema Framework provides one model for this work. OCSF offers a vendor-neutral security schema that can help teams normalise different data sources into a common language for detection and investigation.

A common schema solves only part of the problem, however. Fields can be normalised perfectly and still fail to show that an endpoint process, cloud API request, and SaaS login belong to the same person, service account, or workload. That connection usually comes from identity.

Identity Connects the Evidence

Following Activity Across Systems

Devices are replaced. IP addresses are reassigned. Workloads move between environments. The identity behind an action is often the strongest link between an endpoint event, cloud API call, SaaS login, and permission change.

Identity also changes how an event is interpreted. An employee accessing an application from a managed laptop during normal working hours is not equivalent to a newly created administrator connecting from an unfamiliar device shortly after receiving elevated privileges. The underlying event may be the same. The risk is not.

Analysts need answers to practical questions:

Is the device known and managed?
Is the authentication method normal for this account?
Were privileges granted shortly before the activity?
Has the identity accessed this resource before?
Did the session remain active after a password reset?
Does the action fit the account’s role and recent history?

None of these details proves malicious activity. Together, they tell an analyst whether the alert deserves attention.

Deciding What Needs Attention First

A failed login against an ordinary employee account may be routine. A successful login involving a dormant service account with broad cloud permissions is harder to dismiss. Event type alone cannot express that difference.

Priority should reflect the identity’s role, current privileges, device posture, recent access changes, session history, and the sensitivity of the affected resource. This gives analysts a reason for investigating one event before another, rather than relying on a generic severity assigned by the source product.

Identity can also expose a sequence that separate alerts would miss. Suppose a user signs in from an unfamiliar location, establishes a session on an unmanaged device, joins a privileged group, opens a restricted database, and exports an unusual volume of records.

Any one of those actions might have a legitimate explanation. The sequence, attached to one identity and placed in chronological order, points towards account compromise, privilege escalation, or insider misuse.

Identity monitoring cannot begin and end with authentication. It must cover account creation, privilege assignment, token issuance, resource access, entitlement changes, and deprovisioning.

This matters in everyday cases. A contractor account remains enabled after the contract ends. A new administrator downloads sensitive records immediately after receiving access. A service account starts operating outside its usual workload. Conventional event monitoring may record each action without recognising why it is unusual.

Tokens and active sessions require the same attention. A password reset does not necessarily invalidate every OAuth token, application token, or session cookie previously issued to the user. An attacker holding one of these artefacts may retain access without generating another login event.

Analysts therefore need to follow the session as well as the account. They need to know where the session began, which device created it, what privileges it carried, which resources it touched, and whether it survived the remediation steps taken during the investigation.

With that information in the alert, the analyst receives a connected case rather than a handful of events that must be assembled manually.

Correlation Cannot Fix Bad Data

Unified telemetry makes correlation possible. It does not make the source data accurate.

Stale entitlements, duplicate user records, orphaned group memberships, and service accounts with no confirmed owner can produce conclusions that look convincing but are wrong. If an identity provider reports a role that was removed several days earlier, the SIEM may judge current activity against an outdated privilege record.

Data quality needs a named owner. Failed identity matches, incomplete records, parser errors, stale asset inventories, and unowned accounts should enter an operational queue with clear expectations for correction. Otherwise, the identity graph gradually becomes another source of misleading information.

The graph also contains sensitive information about users, systems, privileges, and relationships. Access to it should be restricted. Searches, exports, rule changes, and administrative actions should be recorded and reviewed. Retention should follow legal and investigative needs, not the assumption that keeping everything forever is inherently safer.

Conclusion

Storing every event connected to an incident does not mean a SIEM can explain what happened. That explanation depends on linking the events to the accounts, workloads, devices, privileges, and sessions involved.

Unified security telemetry gives security tools a shared structure for making those connections. Identity supplies the thread across systems, provided the identity records are current, machine identities are included, and relationships are preserved as access changes.

When attackers operate through valid accounts, stolen sessions, and legitimate administrative tools, an event does not need to look obviously malicious. The better question is whether that action makes sense for that identity, with that access, from that device, at that time.