MJ12

The Problem With a Field Called User

Categories: [Field Notes], [Security]
Tags: [siem], [splunk], [elastic], [security], [logging], [data-normalization], [detection-engineering], [observability]

Security monitoring depends on our ability to combine information from systems that were never designed to speak the same language. Firewalls, operating systems, identity platforms, applications and cloud services all produce events describing different activities, using different formats and often different terminology.

Normalization attempts to solve this problem by giving the data a common structure. Instead of building a separate detection rule for every product, we map events into a consistent set of fields and use those fields for searches, correlation, dashboards and alerting.

It is an entirely reasonable approach and one of the foundations of modern SIEM engineering.

There is, however, an interesting problem hidden inside it. Two events can contain the same field name without describing the same thing. Even more concerning, two perfectly valid data models can assign different meanings to that field.

When that happens, the data can be technically correct while the conclusions drawn from it are wrong.

When the Same Field Describes Different People

Consider a fairly ordinary security event. An administrator modifies another user's account.

The event contains two identities: the administrator who performed the operation and the account affected by it. Depending on the source system, it may also contain an authentication identity, an effective security principal or a service account responsible for executing the change.

All of these identities are relevant, but they describe different roles in the event.

The distinction becomes important when we normalize the data.

Elastic Common Schema (ECS) provides a useful example. For an identity-management operation where one person modifies another person's account, ECS uses the root user fields to describe the actor and user.target to describe the affected identity.

A simplified event could look like this:

{
  "event": {
    "action": "account_updated",
    "outcome": "success"
  },
  "user": {
    "name": "admin-a",
    "target": {
      "name": "user-b"
    }
  },
  "related": {
    "user": ["admin-a", "user-b"]
  }
}

In this example, admin-a performed the operation and user-b was affected by it. The distinction is explicit, and a detection rule can evaluate either identity independently.

Now consider the Splunk Common Information Model (CIM), specifically its Change data model.

For account-management events, the user field describes the account being changed, while src_user describes the identity performing the change.

The same logical event might therefore be represented as:

action=modified
user=user-b
src_user=admin-a

Neither representation is inherently wrong. Both describe the same activity according to the conventions of their respective data models.

But notice what happened.

In one representation, the root user identifies the actor. In the other, user identifies the affected account.

The name stayed the same. Its meaning changed.

This is not a reason to reject either schema. It is a reason to understand the semantic contract behind every normalized field.

Normalization Is a Form of Interpretation

It is tempting to think of normalization as a mechanical process. A vendor provides a field called AccountName, our parser extracts it, and we map it to an appropriate destination field.

In practice, the process requires interpretation.

The source field might represent the account attempting authentication, the account receiving permissions, the owner of a process, the user associated with a network session or the administrator who initiated a configuration change.

Those are not interchangeable concepts.

The problem becomes more complicated when different products use similar names for different roles, or when a single event contains several identities with only limited documentation explaining their relationships.

A parser that successfully extracts every value can still produce a misleading normalized event.

This is particularly important in SIEM environments because normalized fields are rarely used only for display. They become inputs to detection rules, enrichment processes, risk calculations and investigative workflows.

If a detection rule expects user to identify the actor but receives the affected account instead, it may attribute suspicious activity to the wrong identity.

The result is not necessarily a failed search or an obvious parsing error.

It may be a completely valid detection result based on an incorrect interpretation.

That is arguably a more difficult problem to discover, because the system continues operating normally.

The Problem Becomes Visible During Integration

These differences are particularly relevant when organizations consolidate security monitoring platforms, migrate between SIEM products or introduce common detection content across several data sources.

A detection rule developed against one schema may look straightforward to reproduce in another platform. The fields exist, the expected values are present and the search syntax can be translated.

Yet the original rule may contain assumptions that are not immediately visible.

A rule designed to identify administrative changes performed by a privileged account might examine the actor. Another rule may identify sensitive accounts that have been modified, regardless of who performed the operation.

Those rules can operate on the same underlying events while requiring entirely different identity fields.

During a migration, it is possible to preserve the event count, timestamps and visible usernames while accidentally changing which identity the detection evaluates.

A dashboard can suffer from the same problem. A visualization intended to show the most active administrators may instead display the accounts most frequently modified by administrators.

The graph may look reasonable. Its totals may even match expectations.

But it answers a different question.

This is why comparing event counts and confirming field extraction is not enough to validate a SIEM integration. We also need to verify that the normalized fields preserve the relationships described by the original event.

The distinction extends well beyond usernames.

Source and destination addresses, initiating and affected processes, authentication outcomes, object ownership and permission changes all carry contextual meaning that can be lost when events are forced into overly generic structures.

Preserving Context Without Abandoning Normalization

None of this means that normalization is fundamentally flawed.

Without a common data model, every investigation becomes an exercise in remembering vendor-specific field names. Correlation across platforms becomes unnecessarily difficult, and detection content becomes expensive to maintain.

The answer is not to abandon normalization but to avoid treating it as a replacement for the original event.

A useful normalized representation should make the event easier to search while retaining enough information to explain what actually happened.

For security events involving multiple identities, that means preserving their roles rather than merely collecting every username into a single generic field.

It also means preserving the original event, or an adequately faithful representation of it, wherever the collection architecture and retention requirements allow.

The original data provides a way to revisit assumptions when field mappings change, detection logic is updated or an investigation exposes an ambiguity that was not considered during integration.

This becomes particularly valuable over time.

Parsers evolve. Vendor event formats change. Common data models introduce new fields. Detection engineers discover cases that were not covered by the original mapping.

If the source information has been discarded and only an incomplete normalized representation remains, correcting those decisions may become impossible for historical events.

There is a practical balance to maintain here. Retaining everything indefinitely is neither economical nor necessarily useful, and some environments have strict privacy or retention requirements.

But removing source context purely to make every event appear structurally identical can create a different kind of cost: uncertainty about what the data actually means.

Testing the Meaning, Not Just the Parser

Parser testing traditionally concentrates on whether expected fields are extracted and whether the output conforms to the target schema.

That is necessary, but it should be considered the beginning of validation rather than the final result.

For important security event types, a useful test should establish the meaning of the original event before examining its normalized representation.

Consider the account-change example again.

The source event describes an administrator modifying another account. A successful test should confirm not only that both identities are present, but that the actor remains the actor and the target remains the target after normalization.

The test should also establish that the operation and its outcome have been represented correctly.

This matters because some errors cannot be detected by schema validation alone.

A field containing a username is structurally valid whether it contains the administrator or the affected account. A schema validator may have no reason to reject either value.

The semantic error exists only when the value is compared with the intended meaning of the event.

A small collection of representative events can therefore be extremely valuable when developing or maintaining a SIEM integration.

Such examples should include ordinary successful operations as well as unusual cases: administrative actions performed through service accounts, failed changes, privilege escalation and events containing multiple identities.

They become regression tests for the interpretation of security data, not merely for its formatting.

This approach also makes parser changes easier to review. Instead of relying entirely on a visual comparison of configuration files, the team can verify that known events still produce the expected security meaning.

A Common Schema Is Not a Common Understanding

There is a broader architectural lesson here.

Data normalization creates a shared vocabulary, but a shared vocabulary does not automatically produce shared understanding.

A field name is only useful when its meaning is sufficiently clear and consistent for the operations that depend upon it.

In ordinary observability, an ambiguous field may produce an inaccurate dashboard or an inconvenient search result. In security monitoring, the same ambiguity can influence which identity is investigated, which activity is considered suspicious and how an incident is reconstructed.

The consequences depend on the use case, but the underlying engineering problem is the same.

The more automation we build on top of normalized data, the more important these assumptions become.

A manual investigator may notice that two usernames are present and examine the original record. An automated correlation rule will generally apply the logic it was given.

It does not know that the meaning of a field changed during ingestion unless that distinction has been explicitly represented.

This is where data quality becomes part of detection engineering rather than a separate ingestion concern.

What we are trying to achieve

The objective of normalization is to make security data easier to understand, search and correlate without losing the meaning of the original events.

Common schemas such as Elastic ECS and Splunk CIM provide an essential foundation for that work. Their value comes from consistent definitions and predictable relationships between fields, not merely from using familiar field names.

A reliable SIEM integration should therefore be evaluated on more than successful ingestion, correct timestamps and populated fields.

It should preserve who performed an action, who or what was affected, what happened and whether the operation succeeded.

Those relationships are the information that detection rules and investigations ultimately depend upon.

The most useful question to ask during normalization is not simply whether a source field can be mapped to a destination field.

It is whether that mapping preserves the meaning of the event.

Because collecting the correct data is important, but understanding what the data actually says is what makes it useful.