Monad Adds Upwind Support: Route Cloud Security Data by Type, Not by Default

Many security connectors are optimized around one dominant data model, such as network telemetry or authentication events.

Upwind isn't that. One CNAPP produces four structurally different data types, and they don't behave the same way once they leave the source. Configuration findings and threat detections sync incrementally as new records appear. Inventory assets and vulnerability findings are full snapshots, re-pulled on a schedule you set, not a stream you tail. That difference changes how each one should move downstream, what it costs to store, and who ends up looking at it.

Too often, teams don’t treat these data types differently. Everything from Upwind gets forwarded to whatever tool already has an open pipe, usually the SIEM, and it's priced and retained the same way regardless of type. A vulnerability snapshot that re-syncs weekly gets stored at the same per-GB rate as a live detection feed, even though nobody needs to query it in real time. And when everything lands in the same dashboard, a genuinely urgent config finding has to compete for an analyst's attention against a much larger volume of lower-priority findings.

Monad now connects to four distinct Upwind datasets. We built the connectors around the fact that they're four different jobs, not one.

What's we’ve shipped.

Four Upwind connectors are live in Monad today. Each one has its own sync behavior and its own filtering:

• Configuration Findings. Misconfigurations and compliance violations, streamed incrementally as Upwind detects them. Optional Severity Filter and Status Filter (pass or fail) let you narrow what comes through.
• Threat Detections. Runtime detections across network, process, and cloud log activity, enriched with MITRE ATT&CK metadata, streamed incrementally with an optional Severity Filter.
• Vulnerability Findings. CVEs across container images, packages, and cloud resources, pulled as a full snapshot on a cron schedule you control. Optional Severity Filter narrows by CVSS level.
• Inventory Assets. A full snapshot of cloud resources, Kubernetes workloads, and containers, also on a cron schedule. This one works differently from the other three: Upwind requires at least one search condition to run the query, so Cloud Provider is a required field, not optional. If you run multi-cloud, that means one Monad input per provider (AWS, GCP, Azure), each on its own schedule, rather than a single input covering everything.

That last point is worth planning for before setup. A team pulling inventory across three cloud providers needs three inputs, and each one can run on a different cadence if your environment calls for it.

Why the sync model matters as much as the routing

The easy part of any integration is getting the data in. The part that changes an analyst's day is what happens to each type after it lands. A common routing pattern looks like this:”

• Threat detections can be routed straight to the SIEM, since that's where correlation against the rest of your telemetry actually happens and where timely correlation matters.
• Vulnerability findings are often handled as remediation workflows rather than treated as standalone SOC alerts.
• Configuration findings can be routed to whatever compliance tool your audit process runs on.
• Inventory snapshots can be routed to land in a data lake, where they're cheap to store and easy to query later, instead of burning SIEM ingestion budget.

That kind of control doesn't happen by default when every data type is routed through one pipe. Upwind sends four data types out; where each one ends up in your stack is a separate decision. Monad complements Upwind by giving teams control over how each dataset is filtered, normalized, and routed downstream.

Monad can also normalize this data to OCSF if that's the schema your downstream tools expect. That's opt-in, not automatic, and you can normalize to any other schema you want instead. Some teams want Upwind's native schema preserved for a specific destination; others want everything speaking the same language before it reaches the SIEM. Either is fine. The point is you get to decide, instead of the decision being made for you by whichever export format the source happened to use.

Filtering works the same way. Dropping low-severity configuration findings or informational detections before they consume SIEM ingestion budget is real savings, and it's one of the more common reasons teams turn this on. But filtering means choosing not to store something. If your compliance posture requires a complete record regardless of severity, that's a conversation to have before filtering is enabled, not after an audit asks where a finding went.

Where this fits if you're already running Upwind

If you're a security engineer with Upwind already deployed, the value isn't a new dashboard. It's that four different data types finally get four different treatments without building and maintaining OAuth2 client credentials handling, pagination, and four separate sync schedules yourself, or inheriting a script from an engineer who left last year.

If you're evaluating Upwind as part of a broader cloud security data strategy, this is also the moment to decide how config findings, inventory, threat detections, and vulnerabilities should each be handled, before you're three tools deep and reconciling schemas by hand.

Ready to see it running against your own Upwind environment? Schedule a demo and we'll walk through routing configuration findings, inventory, threat detections, and vulnerability data exactly the way your stack needs it.

‍