Control-plane events, next to what actually ran
Posture tools tell you a role is over-permissioned. Runtime tools tell you a process read a credential file. Neither, on its own, tells you that the credential harvested from a pod at 02:14 was used from an unfamiliar address at 02:19. Falak ingests cloud audit logs as OCSF 6003 API Activity into the same store as kernel telemetry, so that sentence is one query.
- CloudTrail, GCP audit and Azure activity as OCSF 6003
- IMDS access from workloads, attributed to a pod
- IAM policy widening and logging-disabled detection
- CIS benchmark results as OCSF 5002 Config State
- Instance identity joined to the runtime sensor
- One retention window, one query language
Capabilities
What it does
Audit logs as first-class events
Control-plane calls are ingested as OCSF 6003 API Activity with the operation, the service, the calling identity and the source endpoint. They sit in the same ClickHouse table as exec and connect events, so correlation is a join rather than an integration project.
IMDS access attributed to a workload
A connection to 169.254.169.254 from inside a container is one of the highest-signal events in a cloud estate. Falak reports it with the pod, the service account and the image that made it, which is what turns it from an alert into a remediation ticket.
Credential use correlated across planes
When a role's credentials are read on an instance and then used from an address that instance has never spoken from, both halves are in the same store. Correlating them is a saved query, not a data-engineering exercise.
Posture that knows what is running
A CIS finding on a host that runs nothing is a backlog item. The same finding on a host that terminates card data is an incident. Posture results carry the same device and cloud context as runtime events, so criticality is inherited rather than re-entered.
Multi-account and multi-cloud
Cloud provider, region, account, organisation and project ride on the OCSF cloud object. Filtering a hunt to one account or one region is a field, not a per-provider special case.
Data residency you can point at
Each tenant is pinned to a region and its events never leave it. The trust page documents exactly what is stored, where, and for how long.
Detections
Representative detection content
| Detection | Technique | Primary signal |
|---|---|---|
| IMDS reached from a workload container | T1552.007 | dst 169.254.169.254 |
| CloudTrail logging stopped or deleted | T1562 | 6003 StopLogging |
| IAM policy widened to wildcard | T1098 | 6003 PutPolicy Action:* |
| AWS credential file read on an instance | T1552.001 | 1001 ~/.aws/credentials |
| Role assumed from an unfamiliar ASN | T1078.004 | 6003 + baseline(asn) |
| Public exposure of a storage bucket | T1530 | 6003 PutBucketAcl |
| Snapshot shared cross-account | T1537 | 6003 ModifySnapshotAttribute |
| Key material exported | T1552 | 6003 GetKeyPolicy / export |
Telemetry collected
- API activity
- OCSF 6003
- Device config state
- OCSF 5002
- Device inventory
- OCSF 5001
- Cloud provider / region
- cloud.provider
- Account and organisation
- cloud.account
- Instance identity
- device.instance_uid
- HTTP request context
- http_request
- CIS benchmark results
- cis_benchmark_result
hunt: credential read, then used elsewhere
class_uid = 1001
and file.path endswith "/.aws/credentials"
and actor.process.name not in ("aws", "terraform")
followed by
class_uid = 6003
and src_endpoint.ip not in baseline("instance_ip", 30d)
within 1h
# One store, one language. No cross-tool export.Stop reconciling two consoles by hand
If your cloud posture and your runtime telemetry live in different products, every correlation is manual. Put them in one schema and see how many questions become one query.