Addition of related.mac and related.port

[hisecu]

At Leiden University we already use the related.port field, and internally there is a demand for
related.mac, which is even more important, and which is flagged as a "must have" by an end user.

In general, the aggregation of related values makes searches far easier for end users.
They do not need to know about all the field names that may contain a port number or a
MAC address, or all the various formats of MAC addresses that are possible.

The reason why related.mac is more important is, that a MAC address has many different
formats in ingest like log entries. Examples are colon-separated hex values like
FF:FF:FF:FF:FF:FF and ff:ff:ff:ff:ff:ff, flat formats like FFFFFFFFFFFF and ffffffffffff,
hyphen-separated values like FF-FF-FF-FF-FF-FF and ff-ff-ff-ff-ff-ff, and dot separated
values like FFFF.FFFF.FFFF and ffff.ffff.ffff. In fact, space separated and
IPv6 Modified EUI-64 are also possible. For the end user, it is difficult to work with this.
If all MAC addresses of all key names are aggregated in related.mac with a canonical format,
which is know to the end user, the search will be very easy.

A fictional example: There is new worm named BogusWorm that uses port 16511/tcp and which
offers a remote exploit to an attacker. It is not known yet whether this port is only used
for incoming traffic or for outgoing traffic as well. There are 30 different candidate
fields that may contain the port number. It makes it easy to be able to simply use a KQL
query like related.port : 16511

It would not surprise me, if the aggregation of even more fields/values would be useful,
our current request is limited to related.port and related.mac

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process?
• If submitting code/script changes, have you verified all tests pass locally using make test?
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes?
• Is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
• Have you added an entry to the CHANGELOG.next.md?

[cla-checker-service]

💚 CLA has been signed

[hisecu]

The contributor license agreement on https://www.elastic.co/contributor-agreement has been signed.

[ebeahan]

@hisecu would you please provide some additional details in the description about the proposed changes and how'd the changes would benefit ECS?

[hisecu]

@ebeahan thanks for your feedback, is that here in the comments or elsewhere?

[ebeahan]

thanks for your feedback, is that here in the comments or elsewhere?

In the PR description is fine.

[hisecu]

thanks for your feedback, is that here in the comments or elsewhere?

In the PR description is fine.

@ebeahan I edited the description above, is it ok like this?

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[trisch-me]

I think an example would be useful here.

[trisch-me]

typo in uppercase ..., The notation...

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[github-actions]

This PR has been automatically closed due to inactivity. If you'd like to
continue working on this, feel free to re-open the PR or create a new one.

Thank you for your contribution!