You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 4, 2022. It is now read-only.
IDS developers have recently started to introduce a cross-vendor, symmetric, reproducible algorithm to derive flow identifiers, called Community ID (see https://github.com/corelight/community-id-spec). This is being adopted at least by Suricata and Zeek/Bro, for now.
It would be useful to have packets stored by stenographer indexed by their community IDs so whole flows can be efficiently extracted at query time for a given ID. This would allow for better interoperability between the detection side (IDS) and the storage side (stenographer).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
IDS developers have recently started to introduce a cross-vendor, symmetric, reproducible algorithm to derive flow identifiers, called Community ID (see https://github.com/corelight/community-id-spec). This is being adopted at least by Suricata and Zeek/Bro, for now.
It would be useful to have packets stored by stenographer indexed by their community IDs so whole flows can be efficiently extracted at query time for a given ID. This would allow for better interoperability between the detection side (IDS) and the storage side (stenographer).
The text was updated successfully, but these errors were encountered: