Tcp midstream fin 5437 v2 #8445
Conversation
As this is a free field and can have any key based on a rule
catenacyber
force-pushed
the
tcp-midstream-fin-5437-v2
branch
from
322b301
to
1a8ef29
Compare
| "properties": { | ||
| "affected_product": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "attack_target": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "created_at": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "deployment": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "former_category": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "malware_family": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "policy": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "signature_severity": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "tag": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "updated_at": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { | ||
| "type": "string" | ||
| } | ||
| } | ||
| }, | ||
| "additionalProperties": false | ||
| "additionalProperties": true |
There was a problem hiding this comment.
Makes sense as this is free-form data from the rule language. Could be anything.
There was a problem hiding this comment.
For our SV it might make sense to be stricter, so we can spot issues?
There was a problem hiding this comment.
I do not think it is an issue to use something which is not in this list, as the ET rules do in OISF/suricata-verify#1051
There was a problem hiding this comment.
For our SV it might make sense to be stricter, so we can spot issues?
I think this would require a separate schema for S-V. The idea of the schema is to produce something re-usable for documentation and code generation purposes, so it doesn't make sense to limit this to only the data that is seen in Suricata-Verify when it really is free-form data.
There was a problem hiding this comment.
I think we should still include the commonly used fields like we have currently, but do allow additional fields.
|
WARNING:
Pipeline 12094 |
|
I've merged in #8536 this without the schema update, as I want to discuss that some more. Should block this work though. |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5437
Describe changes:
suricata-verify-pr: 1051
Replaces #8320 with adding a check so that this only happens for FIN + data packets