Skip to main content

Introducing Padas Motion: Security Streaming Built for the SOC

· 5 min read
Selim Seynur
Selim Seynur
Founder

Padas Motion is our security streaming product. It shapes telemetry while the data is still moving (filter, parse, aggregate, detect, route) and hands cleaner, higher-value events to the tools you already run.

Motion is also the first chapter of a longer arc, it shapes the data while it moves, then Chronos allows organizations to own the context built from it. Motion is the part you can run today.

This post is the introduction; we focus on what's in v0.1.0, how a pipeline is put together, and what a PDL task actually looks like.

TL;DR

  • Padas Motion is a security streaming product: Motion Engine, connectors, and a control plane. It runs as one process, there's no external broker or cluster to stand up first.
  • Processing and detection use the same language, PDL (Padas Domain Language), on the same stream. Tasks are text you keep in a repo and version like code.
  • v0.1.0 is Motion Engine, connectors, and the control-plane UI. Lookup and Search land in v0.2.0. Chronos stays a separate, emerging product.

What Padas Motion is​

Motion is an independent, self-contained security streaming product. This is the v0.1.0 install:

  • Motion Engine : streams and PDL task execution: filter, parse, transform, aggregate, detect.
  • Connectors : config-driven sources and sinks: syslog, HTTP, file, Splunk HEC, Motion-to-Motion TCP.
  • Control-plane UI : streams, tasks, connectors, and metrics in one operator surface.

In practice, shaping happens while the data is still moving: drop events nobody will investigate, collapse duplicates, normalize formats, and route what's left by policy; route some of the events to the SIEM, others to object storage, alerts to wherever they get worked. Sinks write open formats to storage you own, so the shaped data isn't locked inside Motion either.

Motion sits in front of your SIEM/SOAR, not in place of it. It changes what arrives, creating less noise, more signal, and events already shaped for the question you ask downstream, while your SIEM/SOAR keeps doing what it already does well. Motion is also deliberately scoped. It shapes security data in motion. It isn't a SIEM, isn't a data lake, isn't a search product in this release, and isn't generic ETL with a security label.

How Motion is put together​

The figure below is the broader Motion picture. Lookup, Search, Iceberg/catalog, and Chronos ingest are the v0.2.0 (or later) direction, not what you enable on a v0.1.0 node today.

Padas Motion platform map

A few things the map doesn't make obvious. First, the engine runs as a single process with an embedded REST API, there's no broker to provision and no cluster to plan before you see your first event. That's deliberate: getting to a working pipeline shouldn't start with a distributed-systems project.

Second, durability is a decision you make per stream, not a tax you pay up front. Streams hold events in memory by default, with an optional write-ahead log when you want them to survive a restart. Backpressure is part of the stream model rather than something you bolt on when volume climbs.

v0.1.0 in practice. You compose pipelines from as many stream–task pairs as the use case needs. The sample below is a common split: filtered, aggregated events to Splunk for investigation, and raw events to S3 for retention and compliance. S3 here is store-and-keep, not historical Search. Searchable archive query path is v0.2.0, which is also shown in the footer.

Padas Motion sample pipeline: syslog into Motion Engine, aggregated events to Splunk, raw events to S3.

Tasks you can diff​

Those two stages are two PDL tasks, not one. Task 1 parses a syslog-style firewall line and keeps denies. Task 2 windows the filtered stream and forwards a compact line downstream.

Task 1: parse and filter (on the raw stream):

parse_regex raw "(?P<raw_event><\d+>\d?(\s+\S+){6}\s+(?P<kvpayload>.*))"
| parse_kv kvpayload
| action = "deny"

Pull the syslog header and key-value payload, parse the payload into fields, keep action = "deny".

Task 2: aggregate and emit (on the filtered stream):

count() AS total_count, latest(raw_event) AS latest_raw_event timespan=30s group_by srcip, dstip, dstport
| eval raw_line = latest_raw_event + " total_count=" + to_string(total_count)
| output raw_line

Count by source, destination, and port over 30-second windows, append total_count to the latest raw line, and send only that line to the sink.

That is what a Motion task is: text, in one language, for both the parse-and-filter stage and the aggregation stage. You keep it in a repo, review it like any other engineering change, and diff it when someone asks what changed last week. The PDL reference covers the syntax in full.

Where Motion fits​

Padas is a security data company. We help organizations turn security data in motion into governed context they own; governed context meaning context that is customer-owned, with provenance, control, and clear decision boundaries attached, not another dashboard of "insights." Motion is the first step in that arc, and v0.1.0 is available now.

v0.2.0, later this month, is meant to add Lookup (tables on the stream) and Search (historical query over the same PDL). Content packs are still later, not part of that cut. Padas Chronos, our emerging product line for governed context and memory, is designed to turn shaped telemetry into entity context, assertions, and investigation memory. Initial Chronos APIs are aimed at the same window; they stay emerging, and Chronos stays a separate product, not something bolted into Motion.

That ordering is on purpose: context worth trusting has to be built on telemetry you already control. Motion is where that starts.

What's next​

The next post in this series goes inside the Motion Engine; what it actually does with a stream, how streams and tasks fit together at SOC rates, and a deeper taste of PDL. Follow along here, or on LinkedIn, for the rest of the series.