InfluxData Blog - Jamie Strandboge

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 - Jamie Strandboge

Jamie Strandboge (InfluxData) — Wed, 11 Aug 2021 10:51:38 -0700

An unexpected journey

I didn’t set out on my career path, at least not intentionally. After college, I was certain I wanted to write and perform music for a living, but while working at an odd job I discovered I really liked “working with computers”. I didn’t really know what that meant since my degree is in English, so I thought I’d go back to school for Computer Science. While there, a kind professor handed me a copy of RedHat 5.0 (did I just date myself?) so I could do my projects at home, allowing me to help with the baby on the way.

I had compilers and editors and desktops and servers and source code all just in this box of CDs. It was Free, and I was free to tear stuff apart and examine it and learn. Not long after, I moved to Debian and over the next few years bought probably thousands of dollars in computer books and just devoured them. I also got some old IBM computers second-hand and set up a little network to learn all I could about server software, which led me to develop an intense interest in security. It was fantastic.

Fast forward a bit, and I found myself setting up a business with Debian Woody. Back then Debian stable still had the GNOME 1.4 desktop (aliased fonts!) and I found an unofficial set of GNOME 2 packages (anti-aliased fonts! ;), but I really wanted GNOME 2.2 for the business laptops. The developer didn’t plan on providing 2.2 packages, so I took up that work by providing a full, “modern” desktop including Xfree86, evolution, Mozilla, and a whole lot more. I realized that I had a pretty good thing going and thought others could benefit, so I released all of it as the “GNOME 2.2 Backport for Debian Woody” and provided security support and an upgrade path for the backport for more than 3 years until Woody’s end of life. People seemed to really like it, and this experience helped me understand how much good you can bring to people by working on open source software.

Thinking back on my experience and Ubuntu’s roots, it was almost inevitable that I started working for Canonical, where I worked for 13 years in various capacities on the Ubuntu Security team. While there, I learned from my colleagues, stretched and grew. I started doing reactive security but then took on various engineering-focused leadership roles. Eventually I worked for now fellow Influxer Rick Spencer. We worked in earnest on the Ubuntu Phone where I spent most of my time designing and maintaining the application sandbox for the new ‘click’ packaging format. After a while, click packages evolved into snaps where I spent lots of time on its even more ambitious sandboxing mechanism that took advantage of cool Linux security primitives like AppArmor, seccomp, namespaces, capabilities, cgroups and more.

Snaps really took off, and I found myself helping teammates, community members and partners with their applications packaged as snaps by routinely deep-diving into all kinds of disparate topics and codebases like the kernel, systemd, Kubernetes, the chromium content API, robotics, wayland, containerd, polkit, DBus, (what felt like) a gazillion syscalls and on and on. For someone who loves to learn, I learned a lot!

A warm welcome

Late last year, I was ready for a change and I reflected on my career and thought about what was important to me. I serendipitously read Rick’s Why I Joined InfluxDB where he discusses what he feels the three components of loving your job are:

What you do
How you do it
Who you do it with

This really resonated with me. After some wonderful conversations with Rick and other great folks (you know who you are!), I joined InfluxData late last January.

At InfluxData, an important part of our mission is providing great tools and experiences for developers so they can do great things. Since I’m happiest when I’m able to bring value by helping others achieve their goals, what we do as a company aligns perfectly for me. We have a culture of working together, and day-to-day, I’m able to share my experience to help solve interesting problems and learn a bunch of cool new stuff in the process.

In terms of how we do things, open source (an important theme in my career) is the foundation of InfluxData. The heart of our products is open source, we develop with open source tools and we run on infrastructure built on open source. Plus, we are a distributed company, and I’m free to work where I want and free to choose the tools that work best for me (open source of course).

I’ve had the pleasure to work with many great people during my career, but there is something different and special about InfluxData. I had the opportunity to talk with Ryan Betts before starting and he spoke warmly to the importance of culture, inclusion and kindness. This was echoed throughout the hiring process and after I joined. My team and everyone I’ve worked with have all been fantastic! Now I get to experience and be a part of our culture all while working alongside and for passionate, talented and kind people every day.

Six months in, I’m very grateful for the opportunity and so glad I joined.