AWS account identifiers for the population of events with additional data for unique resource_ids

[jeniawhite]

Implement the population of vulnerability events with common data and processors. Make sure that we have everything needed for the generation of unique resource_ids like AWS accounts, ARNs and etc... Basically should be quite similar to AWS CIS.

[eyalkraft]

Reopening to discuss and answer these questions:

• [ ] Should include the EC2 arn? and under what field?
• [ ] Should include the Snapshot arn? and under what field?
• [ ] What should be the resource.type and resource.sub_stype fields?
• [ ] Should a user be able to correlate misconfigurations (from CIS AWS) and vulnerabilities that belong to the same EC2 instance?

Actually checking CIS AWS there's now findings directly related to EC2 machines (see list that should be on our technical index). Maybe an EBS is what we want to correlate?

There's also no resource tab in the vulnerability flyout so product input is required.

@nick-alayil

[uri-weisman]

@eyalkraft IMO, it would be reasonable to include both the volumes and instance identifiers to assist users in correlating resources at the desired level. The resource object should contain all valuable information about machine and volume resources, such as their unique identifiers, names, types, and subtypes. If we choose to group resources by ec2 or ebs, presenting the type | sub-type in the table would be essential.

Answers to your questions:

1. Should include the EC2 arn? and under what field?

Yes, resource.machine.id

2. Should include the Snapshot arn? and under what field?

I'm not sure about snapshot ARN, although it may not benefit the user directly, adding it could assist us with debugging. In case we decide to use it, I would store it under resource.snapshot.

3. What should be the resource.type and resource.sub_stype fields?

I would use the same values we used for CSPM.

**ec2**
type: "cloud-compute"
sub-type: "aws-ec2"

**ebs**
type: "cloud-storage"
sub-type: "aws-ebs"

4. Should a user be able to correlate misconfigurations (from CIS AWS) and vulnerabilities that belong to the same EC2 instance?

Yes, group by instance and group by volume.

To sum things up I would suggest the following schema:

"resource": {
    machine: {
        id: "i-123456789",
        name: "uri-123456789"
        type: "cloud-compute"
        sub-type: "aws-ec2"
    },
    volume: {
        id: "vol-123456789",
        name: "vol-test",
        type: "cloud-storage"
        sub-type: "aws-ebs"
    },
}

[eyalkraft]

Thanks @uri-weisman ! Although I agree with the direction, I think your proposal might not match the criteria defined. Specifically because resource.machine.id and resource.snapshot aren't fields that exist on CSPM findings. So given that ES is missing a "Join" functionality, What queries would you suggest to use to answer these questions:

• Search for all the EC2s that are misconfigured and vulnerable
• Search for all the EBS volumes that are misconfigured and vulnerable

[uri-weisman]

@eyalkraft, I wasn't aware of this requirement, but it seems like a useful feature. However, our benchmark for AWS CIS only includes a single rule for EC2/EBS (2.2.1), so I'm unsure how much value these queries would provide to the user, as the current misconfigurations don't appear to be closely related to EC2/EBS.

Because resource.id can be assigned by either the volume or EC2 ARN, it's challenging to satisfy both needs. If we choose volume as the identifier, it would offer better granularity for the user. Nevertheless, we should still send volume and EC2 data so that group-by can be performed at each level.

Updated schema

resource: {
  id: "vol-123456789",
  machine: {
    id: "i-123456789",
    name: "uri-123456789",
    type: "cloud-compute",
    sub-type: "aws-ec2",
  },
  volume: {
    id: "vol-123456789",
    name: "vol-test",
    type: "cloud-storage",
    sub-type: "aws-ebs",
  },
}

Not sure if should have type and sub-type at the resource level.

[eyalkraft]

Thanks @uri-weisman @tinnytintin10 @nick-alayil I'd love to get your input about what is/isn't a requirement

[nick-alayil]

IIRC, correlating misconfigurations and vulnerability findings wasn't a requirement. However, @eyalkraft's idea is strong. I had actually thought of a demo playbook before and discussed it with @tinnytintin10. In the playbook, an attacker exploits an EC2 misconfiguration to gain access to the EC2 instance and then exploits a vulnerability to gain privileged access. All events are detected using SIEM detection rules and are visualized in the session viewer. However, I abandoned the demo playbook for the same reason that @uri-weisman mentioned above - AWS CIS doesn't extensively evaluate EC2 misconfigurations.

Nonetheless, I do see the value in enhancing vulnerability events with common data and processors, particularly from a SIEM perspective. To prioritize this ticket, is there a way to obtain stats on which integrations currently populate the resource ECS object?

[uri-weisman]

@nick-alayil - I don't think that an ECS resource schema exists today. Those are the supported ecs schemas.

[uri-weisman]

@nick-alayil and I agreed that product will define the resource section first and then I’ll have a clearer understanding of the relevant data we should include in our findings.