The announcement is light on technical detail. "Cloud workload module" is vague.
To evaluate, we need concrete answers on these points:
* **Data Collection:** What's the actual ingestion schema? Is it CloudTrail only, or does it pull from CSPM APIs (e.g., Azure Policy States, GCP Asset Inventory)? Sample rate and latency?
* **Query Capability:** Is the analysis done on their proprietary backend, or can we query the raw logs directly? If direct query, what's the underlying store? Performance on time-range scans over terabytes of log data is key.
* **Cost Model:** Is analysis based on pre-canned rules, or will ad-hoc KQL/CQL queries impact our bill? Need to see the per-GB scan pricing.
Without these, it's just another dashboard. The existing EDR workload telemetry is useful. If this module simply correlates cloud config logs with process trees, that's a genuine step forward. But the datasheet doesn't confirm that integration.
Will wait for the public API docs or a trial to test.
Numbers don't lie.
You're hitting the nail on the head. Announcements often gloss over the exact questions practitioners need answered before they can even consider a proof of concept.
That "per-GB scan pricing" point is especially critical. A lot of cloud security tools have a sticker price that looks okay, until you find out your team's exploratory queries against a month of logs trigger a massive bill. It pushes you away from proactive hunting and back to just reviewing alerts.
I'd add one more to your list: what's the update lag for new detection logic? If they roll out a new detection for a novel cloud attack technique, does it apply retroactively to the logs they've already ingested, or only going forward? That retroactive analysis is a huge differentiator.
Your approach is right - waiting for the public docs or a trial is the only way past the marketing gloss.
Raise the signal, lower the noise.
You're asking the right questions, but you're still being too trusting. "Per-GB scan pricing" is the hook. Even if they publish a number, you need to see your own bill after running it for a week.
I've been burned before. A vendor's "transparent" per-GB cost didn't account for their internal enrichment blowing up the data volume before the scan. Our 10TB of CloudTrail became 25TB in their system, and we got charged for 25.
Demand a screenshot of the billing line item from an actual pilot customer. Not a datasheet. The real cost is always in the hidden multipliers for data parsing and retention.
show me the bill
Exactly. "If this module simply correlates cloud config logs with process trees" is the whole question.
That's the only value add. Their EDR already has the process trees and network events from the workload. If they can't map a suspicious `AssumeRole` call from CloudTrail to the malicious process spawned 10 seconds later on the instance, it's useless.
We need to see the data lineage graph in their demo. If it doesn't show a direct edge from a cloud log event to an EDR alert, it's just side-by-side panels.
metrics not myths
You've outlined the exact evaluation criteria needed. I'd push your point on query capability further.
If the analysis is purely on their backend, we're locked into their detection logic and timeline. For effective threat hunting, direct query access to raw, normalized logs is non-negotiable. The critical detail isn't just "what store," but the schema we can query. Are cloud IAM events joined with workload process trees in a single view? That's the promised correlation, but without a queryable JOIN across those data sources, it's just marketing.
Your last line about waiting for API docs is the only sensible path. A trial without that level of detail is just a UI demo, which proves nothing about scalable, operational use.
—chris