Hi @abr4xc, Welcome to our community! Thanks for trying out Elastic Security with your EDR data!
(BTW, we're working on new Elastic Agent integrations for other EDR solutions, so maybe we'll have an Elastic-supplied version for you in the future). If you can share which EDR this event is from, perhaps we can provide some info.
But for now, as you suggest, you need to get your data into an ECS-compliant, or at least ECS-compatible format.
As background, the Elastic SIEM/Security app, including its external alerts views, detection rules, signals, and detection alerts, requires your data to be indexed in an ECS-compliant format. As I think you know, ECS is an open source, community-developed schema that specifies field names and Elasticsearch data types for each field, and provides descriptions and example usage.
It appears that you've already added
event.kind:alert and some appropriate values for
event.category. So far so good! You've also added
host.name fields, which is great.
However, I do see a few things that are problematic:
- your event does not seem to have an
@timestamp field. I see multiple time fields in your event - you will need to copy one of them to
@timestamp. ECS defines three time fields
@timestamp is mandatory. (ECS definition)
- your event's
threat field will conflict with ECS
- your event's
source field will conflict with ECS
- There may be other issues, such as conflicts with the Elasticsearch field data types you're using in your index mapping template.
Please check out these general guidelines for creating ECS-compliant data:
- Each indexed document (e.g., your log, event, etc.) MUST have the
- Your index mapping template must specify the Elasticsearch field data type for each field as defined by ECS. For example, your
@timestamp field must be of the
date field data type, etc.. This ensures that there will not be any mapping conflicts in your indices.
- The original fields from your log/event SHOULD be copied/renamed/converted to the corresponding ECS-defined field name and data type.
- Additional ECS fields, such as the ECS Categorization fields SHOULD be populated for each log/event, to allow proper inclusion of your data into dashboards and detection rules.
Here's a simple graphic that I created to help get this point across. It appears your data is still in the red zone, and you need to move it at least to the yellow zone to see your EDR alerts appear in the Elastic Security/SIEM app, and then to green to enjoy all the benefits Elastic Security has to offer. It's a bit of work up front, but we think it's worth it.
Can you share where your log data is coming from? (e.g., some security device? or some host computer?)