Our Approach to Working With Data

By Alex Thaman, Chief Technology Officer

In cybersecurity, the volume of data and the cost to store it are an ongoing challenge. Even with a SIEM or data warehouse, storing everything you need over time becomes cost-prohibitive. As a result, security teams end up swiveling across multiple platforms and sources, or excluding certain data altogether. Much of what our customers do involves querying small pieces of data, finding connections, taking notes, and pulling those notes together to build a report. It’s forensics work, which doesn’t depend on having all the data in one place.

Traditional data science centers on complex statistical modeling. Detection engineering instead relies on rules based on known patterns, so those rules are only as good as the patterns that have been learned before. Investigation is different. It’s about making connections across events and data sources. Even when anomaly detection flags something, the analyst gets a small signal that has to be traced through network logs, endpoints, and other sources before it means anything. The analysis doesn’t happen in one place, and neither does the data.

So far, SOC teams have relied on a mix of workarounds, from flipping between tools and screens to consolidating storage and transforming large volumes of data for centralized enrichment and investigation. These workarounds are costly to maintain and make the analyst’s job harder. AI enables a better approach: a layer that reconciles data sources when the data is retrieved, so analysts can work across them without time-consuming, expensive migrations. That’s what we’ve built at Andesite. Instead of juggling multiple tools and query languages, analysts work from a unified view and use natural language to connect the sources.

Our position is simple: investigate where the data lives, and decide what to centralize based on the nature of the data. Andesite is built for the analysis that happens around detection, from connecting related alerts and investigating them to hunting for threats and acting on threat intelligence. It works alongside the SIEM and detection pipeline rather than replacing them.

What makes this practical is the intelligence layer on top. The AI maps each source’s schema when the data is retrieved, so data doesn’t need to be normalized in advance. Analysts can ask questions in natural language instead of learning a different query language for every tool.

Three Key Components of our Approach to Data

Federated Search

One question or goal runs across multiple systems, such as identity providers, EDRs, asset inventories, and network logs, and the results come back together. Analysts don’t have to query each tool.

No ETL

Andesite doesn’t require ingestion or ETL, the process of extracting, transforming, and loading data from different sources into a central repository to investigate it. Our product leaves the data in place, so there’s no costly, risky, and lengthy migration.

Zero-Copy

Instead of building a duplicate data repository, Andesite queries data at its source. Each investigation pulls only the records it needs and creates temporary working copies, keeping storage costs down and data current.

Analyze Data Where It Lives

An AI-enabled solution shouldn’t have to centralize all of the data it analyzes to be effective. Andesite is designed as a zero-copy product: we query data at its origin rather than building a standing duplicate repository of it. When an investigation needs specific records, Andesite retrieves only that minimum required. These records are short-lived working copies subject to retention policy. Beyond them, only the investigation record (tool/API calls, findings, and summaries) is retained.

This also means Andesite doesn’t require ingestion. Not needing to extract, transform, and load (ETL) means customers don’t have to move data into Andesite, or into a proprietary lake, before working with it. Our focus is to make it easier to work with the tools customers already have.

Skipping ETL has three practical benefits. It accelerates time-to-value, because there is no lengthy initial ingestion. It reduces risk, because every large data migration introduces the potential for misconfiguration, data loss, or inaccurate transforms. And it lowers cost, since storage and migration are significant items in security budgets.

Zero-copy is gaining traction in the industry, and it fits some data better than others. Data that is voluminous or follows a common schema is often better kept in one place. For the rest, zero-copy offers important advantages: lower costs and fresher data.

Federated Search: One Question, Many Sources 

Federated search is closely related to eliminating ETL requirements. Instead of writing queries, an analyst gives Andesite a question, a hypothesis to test, or a goal. Andesite works out which systems hold the relevant data, pulls it through their APIs and tools, and brings the results together in one place. Say your endpoint system keeps data for 30 days before moving it to a data lake. An investigation that spans a longer period can draw on both the recent hot data and the cold storage data.

Consider an alert on a suspicious login. To understand it, an analyst needs to tie the user to the device they were on, the device to its network activity, and that activity to any related endpoint or threat intelligence findings. Those answers live in an identity provider, an EDR, network logs, and a third-party feed. Without federated search, the analyst runs each lookup by hand and reconciles the results. Andesite connects them in one investigation. 

The same cross-source view works in other directions too. Andesite can group and relate alerts from multiple sources, so analysts start from a connected picture instead of a pile of separate alerts. It can also take indicators from a threat report and search for them across the enterprise.

Because Andesite sits on top of existing systems, the architecture underneath can change without disrupting analysts’ work. Data migrations are disruptive and slow. Even switching SIEMs means learning a new tool and query language. With Andesite, the interface to the data remains consistent, so security teams can rework their architecture to lower costs and improve latency with minimal operational disruption.

Federation isn’t free, though. Pulling data from a source costs time and sometimes money, and cold storage responds more slowly than a hot tier. That’s why we don’t treat federation as all-or-nothing. We help customers decide which data needs to stay warehoused and which can move to cold storage or remain at the source.

“Our position is simple: investigate where the data lives, and decide what to centralize based on the nature of the data.”

Built for Flexibility

At Andesite, we believe the ideal is a hybrid data architecture: warehouse some data, federate the rest, and keep the freedom to adjust the balance as circumstances change. A vendor raises prices. A SIEM migration begins. A new retention requirement lands. An acquisition brings in a second set of tools and data that will take months to consolidate. Neither extreme handles those shifts well, whether it’s centralizing everything or federating everything.

The right home for a dataset depends on its volume, how often it’s queried, and how quickly answers are needed. High-volume, frequently searched data belongs in an optimized query system. Data that’s too large or too rarely used to justify that cost can stay at the source or move to cheaper storage. Third-party threat intelligence is usually best queried on demand from the provider. Matching each dataset to the right place lets defenders optimize for the data itself.

Investigations follow the evidence wherever it lives. Andesite is built to do the same: retrieve only what an investigation needs, leave the rest where it is, and let the nature of each dataset decide what is worth centralizing. Analysts set the goal and choose how much to automate. They can stay in the loop at each step, or let Andesite run and review the results. Either way, humans stay at the helm, and the architecture underneath remains free to change as costs, vendors, and needs do.

About Alex Thaman

Over a 20+ year career, Alex has been an engineering leader at Microsoft, Unity Software, and Scale AI. At Microsoft, Alex worked on compiler technologies before transitioning to AI. He helped develop Xbox Kinect, Hololens, and Microsoft’s Speech platform. As Chief Architect and Manager for Computer Vision at Unity Software, he developed and led an engineering and product team that worked to simplify the creation of synthetic data to train and test computer vision models. Alex holds a BS with a double major in Computer Science and Math from Purdue University.