InfluxData Blog - Peter Albert

Democratizing Breach Detection: How SMBs Can Build Their Own Time Series Security Monitor

Peter Albert, Jamie Strandboge (InfluxData) — Thu, 27 Aug 2026 08:00:00 +0000

When people hear that the average breach lifecycle still spans hundreds of days, they often blame inefficiency or apathy. The reality is that most teams, especially those in SMBs, are flying blind and relying on logs scattered across dozens of SaaS platforms. The information needed to understand a breach is there, but it often sits behind paywalls or is delivered without enough context to form a coherent picture.

When security events are modeled as time series, they form a continuous stream of behavior rather than isolated snapshots. File downloads, admin actions, and authentication attempts shift from static snapshots to dynamic patterns. Once everything is tracked as a sequence over time, the early signs of trouble become visible far earlier than the consequences do.

Digital Supply Chain Observability

That realization wasn’t theoretical for us. A few years ago, a third-party tool in our pipeline was compromised, and the SaaS didn’t detect it—one of the SaaS’s other customers did. By the time we found out, it was four months since the incident had occurred. That delay made it clear we needed to detect anomalies ourselves, without a full SIEM team or a seven-figure budget.

While that incident wasn’t the sole reason why we did what we did next, it was a catalyst to take security observability into our own hands. We started building an internal monitoring architecture we call DiSCO: Digital Supply Chain Observability. It’s a lightweight, time series-driven system that ingests audit logs from key SaaS platforms we rely on and turns them into an ordered stream of behavior.

The diagram below demonstrates the core idea: small collectors on the left, data collection via Telegraf in the middle, a time series database at the center, and dashboards and alerting tools on the right.

DIY time series security

You don’t need to rebuild DiSCO exactly, but you can build your own version. Here’s a practical path to developing a time series security detection tool without breaking the bank:

Step 1: Map Your Critical SaaS Surface

Start by nominating 5-10 SaaS services critical to your operations or risk profile, such as messaging apps, developer platforms, identity management providers, or financial systems.

Step 2: Secure Access to Audit Logs

Next, determine whether those SaaS tools provide audit logs and what it costs to access them. Many vendors tie log access to higher-priced enterprise plans. While that can feel like a dead end for SMBs, some providers offer off-market plans that include logs without dramatically increasing cost. Continue the conversation and don’t be afraid to negotiate.

If you truly cannot get logs from a particular service, document the gap and revisit it annually.

Step 3: Build Small, Safe Collectors

Once you’ve secured access, you need a way to pull the logs. DiSCO uses a set of small Python applications that:

Authenticate to each SaaS API using a narrowly scoped, read-only token.
Pull new audit events on a schedule.
Hand those events off to a local endpoint for further processing.

You can hand-code these collectors or have an AI system help. Just maintain strict token hygiene: minimal scope, read-only access, and frequent rotation to limit blast radius if a token leaks.

Step 4: Relay Everything Through a Data Collection Agent

Our collectors don’t write directly into the database, but instead send events to a self-hosted Telegraf instance that acts as a buffer and relay. You don’t have to use Telegraf, but its purpose-built support for time series, open source model, and batching capabilities make it a strong option. Events are written into a time series database using line protocol, providing resilience against transient failures.

For storage, you have options:

A purpose-built time series database optimized for high-ingest, high-cardinality data
A relational database (expect more overhead as volume grows)

The core requirement is simple: efficient handling of time-stamped events at scale.

Step 5: Design a Schema That Separates Events from Actions

When logs land, DiSCO writes them into three primary tables or buckets:

A raw logs bucket that stores unmodified SaaS data
A derived actions table with extracted actor, action, IP address, and country information per origin (SaaS)
A normalized events bucket that captures behaviors like logins, downloads, token creation, privilege changes, etc.

To preserve privacy and simplify correlation, we map user identities to UUIDs before storing them in derived tables. Names remain in raw logs for forensics but are excluded from routine monitoring.

Step 6: Add a Simple Inference Engine

With actions normalized and interleaved by time, you can start asking meaningful questions. DiSCO began with a simple inference engine—essentially SQL queries encoding what normal behavior looks like.

We learned typical login times, countries, IP ranges, and action frequencies, then alerted when behavior deviated from those baselines, such as access from a new or suspicious country.

These are basic signals, but they dramatically shorten detection timelines compared to waiting for vendor notification.

Step 7: Layer on Dashboards and a Time Machine

On top of this, we used Grafana to visualize organization-wide behavior at a glance. Because everything is stored as time series data, you gain a “time machine” that lets you replay historical events after improving parsers or adding new logic.

The point: democratize detection

Most SMBs don’t have the budget or staffing to deploy and operate a full SIEM, but they can access SaaS audit logs, write basic collectors, and use free, open source tooling. That’s enough to build a DiSCO-like architecture and reclaim control over breach detection timelines.

If you want to shorten your breach lifecycle, map your SaaS surface, get the logs, normalize events, and learn what “normal” looks like. Then start asking the only question that really matters in breach detection: What just changed?

You don’t need perfect coverage to get value, but you do need motion. The story of a breach is easier to read when it unfolds on a timeline you can see in real-time.

FAQs

What is Digital Supply Chain Observability (DiSCO)?

DiSCO is a lightweight security monitoring architecture that turns audit logs from multiple SaaS platforms into an ordered stream of activity. This allows businesses to monitor their digital supply chain to detect anomalous behaviors without relying on vendor notifications directly.

How can an SMB build a security breach detection system without a SIEM?

An SMB can start by identifying 5-10 critical SaaS services their business relies on, get access to their audit logs, and then start collecting these logs using read-only APIs. The events can then be stored in a time series database for analysis and alerting.

Why is time series data useful for cybersecurity monitoring?

Time series allows you to know the order and timing of security events, making it easier to see patterns that logs alone might hide. Teams can use this data to establish baselines for things like login times, locations, IP addresses, and user activity. Any deviations from these baselines can be used to create alerts to trigger investigations.

How should SaaS audit logs be organized for security analysis?

A good starting point is to separate raw logs from normalized security events. Raw data is kept available for investigation, while the normalized data makes it easier to correlate behaviors like downloads or authentication attempts.

Why I Joined InfluxData, and Why I’m Still Here – Four Years Later

Peter Albert (InfluxData) — Mon, 06 Mar 2023 07:00:00 +0000

Time Series Database.

That term resonated somewhere deep in the structures of my mind, as it jumped off the screen while semi-consciously thumbing through the usual stream of drivel in my LinkedIn feed.

…

Time Series Database? Ah yes, it was somewhere around Y2k at iPass, a global network access provider, which consumed me for more than a decade, and where I first encountered Evan Kaplan, now CEO of InfluxData, the company that created InfluxDB, a time series database.

Suddenly being transported into the past the fog began to clear bit by byte, and I recalled the technology du jour in those days — if you couldn’t afford HP OpenView and were brave enough to experiment with open source — was MRTG (multi-router traffic grapher) and RRDTool (round robin database tool).

At the time, we (iPass) were rolling out a global deployment of data centers with racks of network gear and Unix servers and needed to construct a network operations center rather quickly and efficiently to do the needful work of monitoring.

RRDTool stored time series data such as network bandwidth or CPU load, and MRTG was an open-source graphing tool that provided visualizations and integrated nicely with RRDTool (same developer, thanks Tobi!).

Back then – now more than 20 years ago, these solutions worked nicely for the relatively simple use cases we had, such as determining how many users were on our network at any given point in time.

For many years after that, I would karmically be directly or indirectly involved with time series data. Whether that meant building and using services that incorporated the collection and analysis of time series data, architecting a cloud security management platform built around a time series database, consulting at a fraud monitoring company that generated mathematical models of user behavior derived from time series data, and even receiving a patent along with my InfluxData colleague Darin Fisher for co-designing a global network supply chain monitoring system that performed analysis from multiple time series data input streams.

Time series databases are a logical evolution of the original database abstraction – from the flat, two-dimensional, relational model that represents entities and relationships, to a multi-dimensional model that represents the incremental state changes of each entity over time, specifically the successive moment-to-moment samples of various attributes describing the entity.

A monitoring solution that lacks a time series platform at its core should be considered deficient. While the relational model is useful in defining the ontology or static description of the assets comprising a system, the time series dimensional model is necessary to reflect the continuum of change of each of those assets.

If you consider time as the 4th dimension, we’re talking about a four-dimensional database containing a digital abstraction of change. And that’s cool! The reality is, every object, asset, or entity represented in a relational database is continuously changing with respect to time, which in a sense renders the relational model out-of-date the moment after it is constructed in terms of its ability to provide an accurate representation of current state. Time is the primary manifestation of change. Who said that? And it turns out, an infinity of applications and real-world use cases suddenly arise when regarding time series data.

Not to mention the mystical coolness of a time series database – the mindstream of Buddhism:

The moment-by-moment continuum of mental thoughts, impressions, and occurrences. It is the stream of successive moments of awareness, or movement of the mind.

Clearly the mind was designed with a time series database. Intriguing.

…

So, we return to that LinkedIn feed, when, now more than seven years ago, Evan updated his LinkedIn status saying that he was joining InfluxData as CEO, the company responsible for the InfluxDB time series database, that ring of resonance reverberated within me. We kept in touch over the years after our storied journey together at iPass – an experience that seemed tumultuous at the time, but was also magical and formative for me, and I remain grateful to this day for the doors that Evan opened for me.

Eventually, an opportunity to join InfluxData as its CISO materialized. I just couldn’t help but think of the potential future trajectory of a company that offered a novel, robust, and scalable enterprise-class time series database. Given the state of technological complexity in the world, there’s a need to manage it. For example, the internet of things, where every device needs to be properly accounted for, including all those robots which continue to self-propagate.

It’s also exciting to consider the possibilities for the security industry. A time series database might be instrumental in cloud security breach detection, like how the finance industry models time series data to detect fraudulent financial transactions.

But beyond the coolness of the technology is the quality of the people at InfluxData, starting with its co-founder and CTO, Paul Dix. Not only does Paul walk-the-walk by being actively involved in the technology stewardship of the company, but he has cool shoes too, something I distinctly noticed during my initial visits to the company. And his leadership couldn’t be more evident than the present, as InfluxData announces the launch of its third-generation time series database platform, code named IOx – a project which Paul personally shepherded to completion.

Smart people attract smart people. So as a CISO it was extremely important (and quite a relief!) to know that InfluxData has a very strong and competent engineering team with a deep bench of smart people, who can understand security natively and are both responsive and adaptive to it. The engineering team here continues to humble and astound me on a regular basis.

Obviously the past four years have not been without its trials and tribulations. Shortly after joining the company, the global pandemic arrived and like many other companies, we closed our offices and began the difficult transition to becoming a fully remote workforce without disrupting the business. Only to be followed by a wave of economic uncertainties which, like many technology companies, resulted in organizational changes and lost comrades.

Yet, just like the stability and resiliency you’d expect from a great database, the company and the people have shown great resilience in surfing these waves as they continue to operate and build the next generation of its technology. And like climbing a mountain, every now and then we may need to take a few steps down, traverse over to a new start point, and then resume our ascent. One thing I know about Evan is that he knows how to climb mountains.

Every reason I joined InfluxData in the first place is still evident today. The company continues to maintain its industry-leading technology, appears to have infinite markets to serve, possesses a creative and driven leadership team, and hosts a collective of smart people across the business who are easy and fun to work with. It’s no wonder why I am still here nearly four years later.