-
Notifications
You must be signed in to change notification settings - Fork 563
Review use of non-ecs-schema #1776
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Update Jan 26 2023A lot of this will go away after 2470 is merged. We can shrink this file once it is. In the interim, there are a few rules mentioned below that may have to be tuned due to potentially bad fields.
Internal discussion. We need to find a way to:
|
PR to resolve 1: elastic/integrations#5115 |
PR to resolve 3: elastic/integrations#5120 |
Based on #2520 There are rules in older branches that use integration fields that no longer exist or the integration was renamed. Supporting those rules means that we have to add the fields in the non-ecs-schema file as edge cases (or tune the rules). We should consider those when cleaning up old fields in the non-ecs-schema file. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The exceptions defined in the non-ecs-schema has grown significantly as of late, mostly to accommodate winlogbeat-specific fields.
Old Version
Jan 30th non-ecs-schema
We need to review this as well as the rules using it for:
"powershell.file.script_block_text": "text"
may be definable in winlogbeat.winlog.event_data
, we should look into auto parsing it based on the existence of thewinlogbeat-*
index pattern, similar to how modules and datasets are parsed for filebeat rulesThe text was updated successfully, but these errors were encountered: