Skip to content
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

network_traffic: copy non-ECS fields to ECS-compliant locations for detection rules #8221

Merged
merged 2 commits into from
Nov 27, 2023

Conversation

efd6
Copy link
Contributor

@efd6 efd6 commented Oct 16, 2023

Proposed commit message

Currently, detection rules depend on three non-ECS-compliant fields:

  • type (all except flows)
  • http.request.headers.authorization (http)
  • http.response.headers.content-type (http)

With the exception of flows and icmp, type is already set in network.protocol as well. So make the following copies:

  • type field into network.protocol for icmp
  • http.request.headers.authorization to network_traffic.http.request.headers.authorization for http
  • http.response.headers.content-type to http.response.mime_type for http

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

  • Note query about use of network_traffic.* with http datastream. The issue here is that the field under network_traffic would be http which is an ECS name, and I have seen some issues where use of ECS names is claimed to require ECS conformance even when in a namespaced location. I have doubts about the merits of this position in the long term given that is essentially prevents the use of perfectly cromulent labels.
  • For the new field (assuming it's acceptable), do we want to make the subfields explicitly or dynamically mapped rather than having them as a flattened field.

How to test this PR locally

Related issues

Screenshots

# Detection Rules compatibility
- set:
tag: set_compatibility_request_authorization
field: network_traffic.http.request.headers.authorization
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered using http.request.Headers.authorization instead, but I think a good path (depending on approval of this location) would be to reflect what is currently http.* (without the ECS enrichments) into network_traffic.http.* (and equivalently all <datastream>.* into network_traffic.<datastream>.* in the other datastreams).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that network_traffic.<datastream>.* is a good safe pattern to follow.

There has been a long standing lack of guidance from ECS on the headers field (elastic/ecs#232). With us moving in the direction of open-telemetry I expect us to adapt to their naming conventions at some point. So I figured I should mention that the OTEL definition is singular http.{request,response}.header.<key> (with key lowercased). https://opentelemetry.io/docs/specs/semconv/attributes-registry/http/

@elasticmachine
Copy link

elasticmachine commented Oct 17, 2023

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2023-11-13T21:56:32.891+0000

  • Duration: 68 min 13 sec

Test stats 🧪

Test Results
Failed 0
Passed 154
Skipped 0
Total 154

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@elasticmachine
Copy link

elasticmachine commented Oct 17, 2023

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (1/1) 💚
Files 100.0% (2/2) 💚
Classes 100.0% (2/2) 💚
Methods 98.276% (57/58)
Lines 88.356% (129/146)
Conditionals 100.0% (0/0) 💚

@efd6 efd6 marked this pull request as ready for review October 17, 2023 02:39
@efd6 efd6 requested a review from a team as a code owner October 17, 2023 02:39
@elasticmachine
Copy link

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

Copy link
Contributor

@kcreddy kcreddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Maybe someone with better understanding of detection rules setup could also review it. Thanks!

@@ -1,4 +1,15 @@
# newer versions go on top
- version: "1.26.0"
changes:
- description: Copy `type` field to `network.protocol` in ICPM datastream.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- description: Copy `type` field to `network.protocol` in ICPM datastream.
- description: Copy `type` field to `network.protocol` in ICMP datastream.

Currently, detection rules depend on three non-ECS-compliant fields:

- type (all except flows)
- http.request.headers.authorization (http)
- http.response.headers.content-type (http)

With the exception of flows and icmp, type is already set in network.protocol as
well. So make the following copies:

- type field into network.protocol for icmp
- http.request.headers.authorization to network_traffic.http.request.headers.authorization for http
- http.response.headers.content-type to http.response.mime_type for http
Copy link
Contributor

@brokensound77 brokensound77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good from our end 👍 . We will make adjustments accordingly in elastic/detection-rules#3194

Thank you

# Detection Rules compatibility
- set:
tag: set_compatibility_request_authorization
field: network_traffic.http.request.headers.authorization
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that network_traffic.<datastream>.* is a good safe pattern to follow.

There has been a long standing lack of guidance from ECS on the headers field (elastic/ecs#232). With us moving in the direction of open-telemetry I expect us to adapt to their naming conventions at some point. So I figured I should mention that the OTEL definition is singular http.{request,response}.header.<key> (with key lowercased). https://opentelemetry.io/docs/specs/semconv/attributes-registry/http/

@efd6 efd6 merged commit 8450394 into elastic:main Nov 27, 2023
4 checks passed
@elasticmachine
Copy link

Package network_traffic - 1.27.0 containing this change is available at https://epr.elastic.co/search?package=network_traffic

2 similar comments
@elasticmachine
Copy link

Package network_traffic - 1.27.0 containing this change is available at https://epr.elastic.co/search?package=network_traffic

@elasticmachine
Copy link

Package network_traffic - 1.27.0 containing this change is available at https://epr.elastic.co/search?package=network_traffic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants