- Issue created by @jurgenhaas
- 🇫🇷France rr404
Some additional details for the context:
- For a given signal you can add the $property["context"] when you use Watcher::buildSignal
- "context is an array of objects : "context":[{"key":"exampleKey1","value":"exampleValue1"}]
- you can pass multiple similar keys, for example for a scan alert you can pass all the target_uri that were part of the detection of this alert if you have them:
- context":[{"key":"target_uri","value":"adminroot.php"},{"key":"target_uri","value":"user/edit.php"}]Here are the context keys that would be very good to have in signals:
- "target_uri":"the HTTP path of the requests that were part of the scan alert. Ideally all the ones involved in the alert"
- "user_agent":"User agent of the attacker"
- "method":"the HTTP verb used GET, POST..."
- "status": "the HTTP status returned or that would have been returned"
-"target_user":"in case of bruteforce, the user(s) on which the addempts were made by the attacker" - 🇫🇷France rr404
Other feature taht would be very usefull to users is to see some metrics of what has been blocked in order to perceive the value of both the detection of the plugin and the preemptive protection from the community blocklist
The count of remediation actions by origin (name of the list that contained the IP to block) is already handled by the SDK
- 🇩🇪Germany jurgenhaas Gottmadingen
The expected enhancements don't seem to require a new major release, a new minor is sufficient for that. So, I changed the target version to 1.2 and created child issues for each of the 3 feature requests that should be implemented.
