Cloudtrail add origin and target

[romulets]

WIP

[romulets]

@tinnytintin10 For the AttachUserPolicy event it was unclear what target should I use.

What happens is:

romulo attached policy Audit to user tinsae.

The natural target would be tinsae. But I wonder what to do with the Policy arn.

Wdyt?

[tinnytintin10]

We should capture both the user and the policy as targets for now since they are both key pieces of information. If we only capture the user, the analyst would need to look through the event details (in nested fields) to identify the attached policy, and if we only capture the policy, they'd have to do the same to identify the affected user. Capturing both makes it easier to understand the full context of the event.

When looking at the sample/test log for this event, i noticed that while we get the arn for the policy, we only get the username of the iam user involved (test-cloudtrail). I suggest templatizing the creation of an ARN for the user and using this arn value in as one of the target ids:

arn:aws:iam::{accountId}:user/{userName}

Using the ARN helps indicate that it's an IAM user, similar to how the ARN for the policy inherently clarifies that it's a policy. This approach should make it more apparent in the data (target.id's value) what each entity is. Then, in the user.target.* ECS fields, we can capture both the arn/id and name (user.target.name, user.target.id). wdyt?

That being said, even if we decide not to go down the route of templatizing the creation of the arn and just use the userName as the tatget.id, let's ensure the target username value is captured under user.target.name too.

@terrancedejesus @imays11 @shashank-elastic would love to hear what you think for the case above

[tinnytintin10]

Another approach here could be to follow how the target field is used in existing ECS fields like user. For example:

Currently in ECS, if we wanted to normalize an IAM-related event where a user (tin) is added to a group (test-group) by user romulo, we would represent it like this (see the ECS documentation for reference):

{
  "user": {
    "name": "romulo",
    "target": {
      "name": "tin",
      "group": { "name": "test-group" }
    }
  }
}

A few points to note here:

• The target field nested under user inherits the user.* fieldset.
• The group field nested under user.target is a standalone ECS fieldset used to normalize “group” entities (e.g., IAM groups), which can be nested under the user.* fieldset.

Applying a similar approach to our scenario—where IAM user romulo (actor) attached the IAM policy Audit to IAM user tin (target)—we could represent the actors and target like this:

{
  "actor": {
    "entity": {
      "id": "arn:aws:iam::123456789012:user/romulo"
    }
  },
  "target": {
    "entity": {
      "id": "arn:aws:iam::123456789012:user/tin",
      "target": {
        "id": "arn:aws:iam::aws:policy/SecurityAudit"
      }
    }
  }
}

Since this event only has one actor and one target, we could also add more metadata to the entity fields to help with rendering the nodes in the graph visualization (cc @kfirpeled):

{
  "actor": {
    "entity": {
      "id": "arn:aws:iam::123456789012:user/romulo",
      "type": "AWS IAM User"
    }
  },
  "target": {
    "entity": {
      "id": "arn:aws:iam::123456789012:user/tin",
      "type": "AWS IAM User",
      "target": {
        "id": "arn:aws:iam::aws:policy/SecurityAudit",
        "type": "AWS IAM Policy"
      }
    }
  }
}

From a design perspective (cc @codearos), this could look something like:

@romulets, what do you think?

[romulets]

Regarding the templatizing the ARN field, this should be covered by https://github.com/elastic/security-team/issues/10650. Therefore I suggest we focus this PR on what are we storing, and we take care of trying to have a few identifiers as ARN (like user). Why do I say a few? I don't think it's worth to normalize it for services that traditionally are not ARN first, like ec2. Of course this is up to discussion.

Regarding on how to represent the impacted entity, I believe having a target, inside a target, it's confusing.

What I suggest, then, is to have another field something like affectedEntity or eventProduct, eventMaterial, or something like that - had not had a great idea for naming I believe.

Being the goal of that field to solely represent entities that weren't necessarily targeted, but were either used or changed as part of the event.

Something like:

{
  "actor": {
    "entity": {
      "id": ["arn:aws:iam::123456789012:user/romulo"]
    }
  },
  "target": {
    "entity": {
      "id": ["arn:aws:iam::123456789012:user/tin"] 
    }
  },
  "affected": {
     "entity": {
      "id": ["arn:aws:iam::aws:policy/SecurityAudit"]
    }
  }
}

What do you think?

ps: I intentionally kept the type out because we are not covering that on this PR.
ps2: Also intentionally made all values arrays because that's how we are going to store it

[romulets]

@tinnytintin10 and I hoped in a call and came up with the following idea:

The attached policy is also a target, but it has a different relationship description. And that seems to be needed from a graph perspective only. So what we could do is leverage what @kfirpeled has proposed with AdditionInfo and add a relationshipLabel field there.

e.g.:

{
  "actor": {
    "entity": {
      "id": [
        "arn:aws:iam::123456789012:user/romulo"
      ]
    }
  },
  "target": {
    "entity": {
      "id": [
        "arn:aws:iam::123456789012:user/tin",
        "arn:aws:iam::aws:policy/SecurityAudit"
      ],
      "additionalInfo": {
        "arn:aws:iam::aws:policy/SecurityAudit": {
          "relationshipLabel": "Attached User Policy"
        },
        "arn:aws:iam::123456789012:user/tin": {
          "relationshipLabel": "Was attached"
        }
      }
    }
  }
}

Of course this can also be a applied to what @eyalkraft suggests on keeping all the metadata of entities inside another field called entities. Once we decide where will we keep the entities metadata, then we can take a decision of where to keep this information. But the good news are is that it doesn't seem to be that much work on top of what we already have and have planned.

[romulets]

@tinnytintin10 I wonder what to do with delete network acl entry, because each entry doesn't have its own id - but has an acl + a manual rule number

[tinnytintin10]

I'm not entirely sure about this. ACL rule IDs are just numbers, in this case, 100. These numbers aren't unique across ACLs. This means you can have acl-foo and acl-bar, both with a rule with the ID of 1. These rules aren't the same and probably allow or deny different types of traffic or network behavior in two different ACLs associated with different VPCs. With this in mind, just having 100 as the ID of the rule isn't ideal, especially once we begin graphing it.

We could:

• Prepend the rule ID with the {acl-id} rule-id: {rule id} and track two targets for this action.
• Treat only the ACL as the main target and track the ACL rule as metadata or priorities about the ACL somewhere in target.entity.*

I'm not sure what the right path is... Let me think more on this and get back to you tomorrow...

[tinnytintin10]

@terrancedejesus @imays11 @shashank-elastic wdyt?

[romulets]

@tinnytintin10 on AuthorizeSecurityGroupIngress do we consider the security group as target or the underlying security group rule as target?

[romulets]

On PutBucketReplication we can have the bucket we are replicating from, the bucket we are replicating to and both. What is the best @tinnytintin10 ?

[romulets]

On PutObject we can have the bucket, the object, or both. What do you think @tinnytintin10 ?

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elastic-sonarqube]

Quality Gate failed

Failed conditions
6 New issues

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 8f088ee

History

• 💔 Build #17312 failed 54a33d7
• 💔 Build #17309 failed 9986273
• 💔 Build #17306 failed 94a4662
• 💔 Build #17225 failed 011549d
• 💔 Build #17154 failed 7328380