Threats, correlated across your cloud logs
A cloud SIEM ingests CloudTrail, GuardDuty, VPC Flow and identity logs, correlates them into incidents and alerts your SOC. Today CloudLens reads your GuardDuty threats and exports every finding for your SIEM to ingest — it is a source for your SIEM, not a SIEM itself. Native log ingestion, retention and correlation is on our roadmap, and we'd rather say so than fake a console.
This capability is not available in CloudLens yet. We would rather say so than show a screen that does not exist. Here is what we are building and what you can use today.
Where Cloud SIEM is headed
Ingest the raw log sources
CloudTrail trails, VPC Flow, EKS audit and identity logs — not just the 90-day event history we read today — so the events a SIEM correlates live in one place, read-only.
Correlate events into one incident
A login from a new geo, then mass S3 reads, then an IAM policy change become a single timeline — not three unlinked alerts in three tools.
Alert the SOC, tied to the graph
Every detection links back to the resource, its exposure and its role, so responders see blast radius — not just a log line.
What CloudLens already covers
These ship now and cover much of the same ground.
We already read every account's GuardDuty findings and surface each threat on the exact resource it hit, with its exposure, identity and reach.
Every finding exports as JSON (one flat record per row, account stamped) — ready for Splunk, Sentinel, Chronicle or any pipeline to ingest.
What a compromised workload can actually reach — internet → workload → role → data — so an alert comes with blast radius.
Tell us how you would use it
Ready to see CloudLens in action?
Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.