-
Notifications
You must be signed in to change notification settings - Fork 11
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
[IDEA] Make Alert Formats Consistent #155
Labels
enhancement
New feature or request
Milestone
Comments
8 tasks
HugoSoszynski
added a commit
that referenced
this issue
Jul 17, 2020
# ✨ Pull Request Template‼️ Once all the **checklist** is **done** you have to: * **stash merge** this pull request * **delete** the corresponding **branch** * **close** the associated **issue** ## 📃 Type of change **Bug fix**: non-breaking change which fixes an issue. **Breaking change**: fix or feature that would cause existing functionality to not work as expected. ## 💡 Related Issue(s) - Resolve #155 ## ✒️ Description ### Breaking Changes **BREAKING**: The existing alert format is replaced by a more uniform one. The goal is to make it easier to read, parse, query and display. The alert formatting is no longer hard coded in the filters to avoid mistakes. The ability to add tags to the alert raised was implemented. By default the filters might contains some MITRE tags indicating plausible threats type. It can be configured through the `alert_tags` optional string list. ### The new alert format ``` { "alert_type": "darwin", "alert_subtype": "<filter_name>", "alert_time": "<ISO8601>", "level": "high", "rule_name": "<rule_name>", "tags": ["<tag_0>", "<tag_1>", ...], "entry": "<filter_input>", "score": <integer>, "details": { "feed": "<the_threat_intell_feed_name>", "description": "<threat_description>", "udp_nb_host": <float, number of unique host connected via udp>, "udp_nb_port": <float, number of unique port connected via udp>, "tcp_nb_host": <float, number of unique host connected via tcp>, "tcp_nb_port": <float, number of unique port connected via tcp>, "distance": <float, distance to the closest normal asset> } } ``` The `rule_name` contains a short description of the alert for display purposes. The fields in the `details` json will vary given the filter raising the alert. Refer to the filter's documentation for details. ### Fixes - FAnomaly, alert was not raised when the output format was not `LOG`. - Multiple compilation warnings. - Issues with a recent merge in the automated testing. - Multiple missing parameters errors in the manager. ## 🎯 Test Environments ### HardenedBSD 12-STABLE - Redis 5.0.8 - Boost 1.72.0 - clang++ 9.0.1 - CMake 3.17.1 - Python 3.7.7 ## ✔️ Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added corresponding page to the documentation - [x] I have made corresponding changes to the documentation - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes </br> - [x] 🙋 **I certify on my honor that all the information provided is true, and I've done all I can to deliver a high quality code** Co-authored-by: frikilax <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is your feature about ?
rework/uniformize filters alerts
Describe what you'd like
Filters logs are inconsistent, there should be well-known fields in the json log line, with comprehensive details about the given alert
Additional context
for example "connection" returns a field "connection": "1.2.3.4;5.6.7.8;32966;6", change it to something like "details": "1.2.3.4:32966 -> 5.6.7.8:6".
"content_inspection" returns a "yara_match", dga returns "domain"...
The text was updated successfully, but these errors were encountered: