Correlate Okta and CloudTrail Events in Falco for Identity Threat Detection (2026)

Okta and CloudTrail events don’t just correlate; they converge to paint a picture of identity-driven threats that neither could show alone.

Let’s see this in action. Imagine an attacker has compromised an Okta user account. They might then try to access sensitive AWS resources using that compromised identity.

Here’s a simplified falco_rules.yaml snippet that looks for suspicious Okta login events and then tries to correlate them with subsequent AWS API calls made by the same user:

- rule: Suspicious Okta Login followed by AWS activity
  desc: Detects a user logging into Okta from an unusual IP or location, and then making API calls in AWS within a short timeframe.
  condition: >
    (okta.event.type = "user.session.start" and okta.event.outcome.result = "SUCCESS")
    or
    (okta.event.type = "user.session.extend" and okta.event.outcome.result = "SUCCESS")
  append:
    - okta.user.id
    - okta.user.login
    - okta.client.ip_address
    - okta.client.geographical_context.city
    - okta.client.geographical_context.country

  condition_output: "Okta Login: User {{okta.user.login}} ({{okta.user.id}}) from {{okta.client.ip_address}} ({{okta.client.geographical_context.city}}, {{okta.client.geographical_context.country}})"

  enabled: true

- rule: AWS API Call after Suspicious Okta Login
  desc: Correlates suspicious Okta logins with subsequent AWS API calls from the same user.
  condition: >
    (okta.event.type = "user.session.start" or okta.event.type = "user.session.extend") and
    okta.event.outcome.result = "SUCCESS" and
    evt.time < (evt.time + 300) and # Within 5 minutes
    evt.time > (evt.time - 300) and

    aws.user.arn = "arn:aws:iam::{{okta.user.id}}:user/*" # This is a simplification, real correlation needs better mapping

  append:
    - okta.user.id
    - okta.user.login
    - okta.client.ip_address
    - aws.operation
    - aws.user.arn

  condition_output: "AWS Activity after Okta Login: Okta User {{okta.user.login}} ({{okta.user.id}}) from {{okta.client.ip_address}} made AWS API call {{aws.operation}} (ARN: {{aws.user.arn}})"

  enabled: true

This isn’t magic; it’s about bridging two distinct logging worlds. Okta logs who is logging in and from where. CloudTrail logs what actions are being taken in AWS. By enriching Falco with both Okta event data and AWS CloudTrail data, you create a unified view.

The core problem this solves is the blind spot between identity management and cloud infrastructure. A compromised Okta account is just an inconvenience until it’s used to do something harmful in AWS. Falco, when fed both streams, can detect that sequence.

How it works internally:

1. Okta Event Ingestion: You’ll need a mechanism (like a custom Okta integration or a log forwarding app) to send Okta system logs to a place Falco can read them. This could be a Kafka topic, a file, or directly into a SIEM that Falco queries. Falco’s okta plugin (or a generic file/syslog input) picks these up. These events contain fields like okta.event.type, okta.user.login, okta.client.ip_address, and okta.outcome.result.
2. CloudTrail Event Ingestion: Similarly, CloudTrail logs need to be sent to Falco. This is commonly done by configuring CloudTrail to send logs to an S3 bucket, then having a mechanism (like a Lambda function or a direct S3-to-Kafka connector) push those logs to a Kafka topic that Falco consumes. CloudTrail events are parsed by Falco into fields like aws.operation, aws.user.arn, aws.eventTime, and aws.userIdentity.arn.
3. Falco Rule Correlation: The Falco rule above uses a combination of field matching and temporal proximity.

   • okta.event.type = "user.session.start" or okta.event.type = "user.session.extend": This part looks for successful Okta session establishment.

   • okta.event.outcome.result = "SUCCESS": Ensures it was a legitimate login.

   • evt.time < (evt.time + 300) and evt.time > (evt.time - 300): This is the temporal window. Falco evaluates rules sequentially. When an Okta event triggers, Falco holds onto its context (like okta.user.id). If a CloudTrail event occurs within 300 seconds (5 minutes) of that Okta event, and the aws.user.arn can be mapped to the okta.user.id, the rule fires. The aws.user.arn = "arn:aws:iam::{{okta.user.id}}:user/*" is a naive example; real-world mapping often requires an identity provider’s configuration or a lookup table to translate Okta user IDs to AWS IAM ARNs.

The exact levers you control are the data sources you feed into Falco and the logic within your Falco rules. You define what constitutes "suspicious" for Okta logins (e.g., impossible travel, logins from known malicious IPs, brute-force attempts) and what subsequent AWS actions are considered high-risk.

One thing most people don’t realize is how critical the identity mapping is. Okta uses its own user identifiers, and AWS uses IAM ARNs. For correlation to work beyond simple IP matching, you need a reliable way to link an Okta user to their corresponding AWS IAM entity. This is often achieved through Okta’s integration with AWS as an Identity Provider (IdP), where Okta assertions can map to IAM roles. Falco can ingest these enriched events if your logging pipeline is set up correctly.

The next step is to move beyond simple detection to automated response.