How Vega Changed the Way We Investigate

For a long time, I believed the challenges I encountered during incident response were the unavoidable costs of the job. I knew these problems could be solved, but every solution seemed too complex and too costly to implement. It wasn't until I learned how Vega approaches federated search that I realized many of these challenges weren't inevitable after all.

If you've ever responded to a security incident, you've probably experienced the same thing.

Rapid and effective incident response depends on having a clear, comprehensive understanding of both the threat and the target. Containment and eradication require investigators to identify attack vectors, build an attack timeline, understand attacker tactics, techniques, and procedures (TTPs), and continuously monitor the adversary's operational flow throughout the environment. And none of this is easy.

Throughout my years as an incident responder, I worked across organizations from different industries, each with completely different environments, security stacks, telemetry sources, and operational maturity levels. No two incidents were ever the same. But almost every investigation started with the same challenge: before we could answer investigative questions, we first had to understand what data existed and where it lived.

The First Challenge: Understanding What You Can See

From the moment an organization realizes it has been compromised until the investigation team can actually begin investigating, a critical amount of time is often lost.

Permissions need to be approved. Access needs to be granted. Relevant data sources need to be identified. Query syntax needs to be learned. Telemetry coverage needs to be validated.

And during all of this, the attacker keeps moving.

The investigation rarely stopped at the security information and event management (SIEM) platform. There was always another source of evidence: an endpoint detection and response (EDR) platform, firewall telemetry, VPN logs, email security alerts, Sysmon data, browser history, cloud telemetry, or some internal system that was never centralized into the SIEM.

And more often than not, it turned out to be the most important one - the source that contained the missing piece needed to understand what actually happened.

And if that's not enough, sometimes the data existed, but the parsing was broken. Sometimes critical fields weren't extracted, and nobody noticed until the middle of the investigation - when the team discovered it had been working with an incomplete picture all along.

Even organizations with mature SOC teams and centralized SIEM platforms struggled with these challenges.

I remember incidents where everyone believed critical assets were fully monitored, only to discover that the endpoint running the attacker’s tooling had an outdated EDR agent generating incomplete telemetry - if any telemetry at all.

The challenges are everywhere, just like the data.

What Investigations Actually Look Like

Take a ransomware investigation, for example.

An organization is compromised. Almost every server is encrypted, a ransom note has been left behind, and the network is disconnected. The organization is not operational, and every hour matters.

The investigation needs to move fast, but there is a lot of data to cover. The organization wants answers. What happened? How did it happen?

Before those questions can be answered, investigators need to reconstruct the attack: identify the initial compromise, determine whether persistence was established, and trace the threat actor's movement through the environment.

Much of the data needed to answer these questions already exists. But it's not in one place.

Take a simple question: which process executed the encryptor?

The data exists in Windows Event Logs, Sysmon, EDR telemetry, and forensic artifacts.

Each source exposes the information differently, forcing investigators to repeat the same search multiple times.

Same investigation. Same question. Different platform, different schema, different workflow.

And eventually comes the question every incident response team expects: was data exfiltrated?

Again, the answer may exist in firewall logs, proxy logs, EDR telemetry, cloud logs, or network monitoring platforms.

Each source provides a different piece of the puzzle and requires its own search.

Same investigation. Same question. Different platform, different schema, different workflow.

At some point, the frustration becomes obvious. Even when the data exists, we're still struggling because we're forced to ask the same investigative question over and over again across different tools and data sources.

This is what investigations look like. This is the part nobody talks about.

The Investigation Doesn't Stop There

Throughout the entire investigation, one challenge keeps repeating itself: hunting indicators of compromise (IOCs).

Every investigative answer uncovers new indicators, each becoming another lead that needs to be followed across the environment. With every new IOC, investigators rewrite the same search across different products, schemas, field names, and query syntaxes.

Every additional pivot increases the chance that a data source is overlooked, a query is written incorrectly, and eventually an IOC is missed. All the while, you're wondering: was the field name wrong? Did a query silently fail? Is there a visibility gap nobody noticed?

One platform uses sha256.
Another uses SHA256Hash.
A third uses file.hash.sha256.

The indicator never changed. Only the way we had to search for it did.

What we really needed was simple: the ability to ask a question across all available telemetry.

The Pattern Behind Every Investigation

The more investigations I worked on, the more obvious the pattern became.

We were struggling because every investigation started with figuring out where the data lived, how to access it, and how to query it.

The challenge was rarely the lack of data.

The challenge was finding it, accessing it, understanding it, and asking the same investigative question across all of it.

That's what immediately resonated with me the first time I experienced true federated search - one place to search the entire security stack.

Querying Data Where It Lives

Instead of forcing organizations to centralize every data source for visibility, Vega queries the data where it already lives.

The firewall that never made it into the SIEM, the EDR platform with its own isolated interface, the cloud logs that were too expensive to ingest - they all become queryable from day one.

Investigators no longer need to spend valuable time figuring out where the data lives, how to access it, or which product to pivot into next. Available data sources are visible from the start, queries run from a single place, and investigators can immediately focus on answering the questions that matter.

Faster answers lead to faster containment, faster remediation, and a faster return to normal business operations.

Figure 1. Vega makes all available data sources visible from the start.

Normalization solves the schema problem: Vega maps telemetry from every connected source into a unified structure. sha256, SHA256Hash, and file.hash.sha256 all become the same field.

One query - written once in Vega KQL, or even in natural language - runs simultaneously across every connected source that holds that type of data.

Figure 2. One query. One schema. Multiple data sources

Investigators no longer need to maintain multiple query variants, pivot manually between platforms, or worry that a field mismatch silently caused them to miss critical evidence.

Visibility gaps are surfaced continuously.

Instead of discovering blind spots during an active incident, investigators can focus on identifying missing telemetry coverage before the investigation even begins.

These were the exact problems we struggled with during real incidents - problems many investigators accepted as part of the job.

They're also the problems Vega was built to solve.

‍