I am creating a parser extension to append new values to the security_result.rules_labels that is already being used by the default parser. The following is the extension I created :
filter {
mutate {
replace => {
"security_result" => ""
"psp_security_result" => ""
}
}
json {
source => "message"
array_function => "split_columns"
on_error => "_not_json"
}
if [_not_json] {
drop {
tag => "TAG_MALFORMED_MESSAGE"
}
}
else {
mutate {
replace => {
"var_matched_field_value.value" =>
"%{jsonPayload.previewSecurityPolicy.matchedFieldValue}"
}
on_error => "no_matched_field_value"
}
if ![no_matched_field_value] and [var_matched_field_value][value] != "" {
mutate {
replace => {
"var_matched_field_value.key" => "matched_field_value"
}
}
mutate {
merge => {
"security_result.rule_labels" => "var_matched_field_value"
}
}
}
mutate {
convert => {
"jsonPayload.previewSecurityPolicy.matchedLength" => "string"
}
on_error => "already_a_string"
}
mutate {
replace => {
"var_matched_length.value" =>
"%{jsonPayload.previewSecurityPolicy.matchedLength}"
}
on_error => "no_matched_length"
}
if ![no_matched_length] and [var_matched_length][value] != "" {
mutate {
replace => {
"var_matched_length.key" => "matched_length"
}
}
mutate {
merge => {
"security_result.rule_labels" => "var_matched_length"
}
}
}
mutate {
convert => {
"jsonPayload.enforcedSecurityPolicy.matchedOffset" => "string"
}
on_error => "already_a_string"
}
mutate {
replace => {
"var_enforcedSecurityPolicy_matchedoffset.value" =>
"%{jsonPayload.enforcedSecurityPolicy.matchedOffset}"
}
on_error => "no_enforcedSecurityPolicy_matchedoffset"
}
if ![no_enforcedSecurityPolicy_matchedoffset] and
[var_enforcedSecurityPolicy_matchedoffset][value] != "" {
mutate {
replace => {
"var_enforcedSecurityPolicy_matchedoffset.key" =>
"enforcedSecurityPolicy_matchedoffset"
}
}
mutate {
merge => {
"psp_security_result.rule_labels" =>
"var_enforcedSecurityPolicy_matchedoffset"
}
}
}
mutate {
convert => {
"jsonPayload.enforcedSecurityPolicy.matchedFieldLength" => "string"
}
on_error => "already_a_string"
}
mutate {
replace => {
"var_enforcedSecurityPolicy_matchedfieldslength.value" =>
"%{jsonPayload.enforcedSecurityPolicy.matchedFieldLength}"
}
on_error => "no_enforcedSecurityPolicy_matchedfieldslength"
}
if ![no_enforcedSecurityPolicy_matchedfieldslength] and
[var_enforcedSecurityPolicy_matchedfieldslength][value] != "" {
mutate {
replace => {
"var_enforcedSecurityPolicy_matchedfieldslength.key" =>
"enforcedSecurityPolicy_matchedfieldslength"
}
}
mutate {
merge => {
"psp_security_result.rule_labels" =>
"var_enforcedSecurityPolicy_matchedfieldslength"
}
}
}
if [security_result] != "" {
mutate {
merge => {
"event.idm.read_only_udm.security_result" => "security_result"
}
}
}
if [psp_security_result] != "" {
mutate {
merge => {
"event.idm.read_only_udm.security_result" => "psp_security_result"
}
}
}
mutate {
merge => {
"@output" => "event"
}
}
}
}
The behaviour from this extension does not add values to security_result.rule_labels but overrides the values mapped by the default parser.
My question is, how can I change the behaviour in a way I donยดt override the values provided by the default parser but instead I add values to the existing ones in security_result.rule_labels ?
Solved! Go to Solution.
Known issue unfortunately. Anything repeated gets replaced not appended to. So not only will it wipe out your labels, but ALL your security result. (Please please fix it Google ๐) We "go around" it either by overriding the parser (not preferred) or by using src.security_result instead and as an alternative - src is a rarely used field unlikely to have data in it so we kind of hijack it. Neither is ideal of course. If the addition is too minor i would use src.security result. if the parser mixes up ALLOW and BLOCK for example or makes some error that will just hurt experience, I would go into the custom parser and fix it at the source. We lose updates this way unfortunately, so it's wise to submit a support ticket and request for that fix to be made in the parser itself and then revert back to default. We try to keep any custom parser changes to minimal and only necessary, and still have an extension for the cosmetic stuff to make it easy to upgrade it to default once big issues are handled.
Long story short - avoid repeated fields for extensions. It appears to work for additional though, which is good.
Known issue unfortunately. Anything repeated gets replaced not appended to. So not only will it wipe out your labels, but ALL your security result. (Please please fix it Google ๐) We "go around" it either by overriding the parser (not preferred) or by using src.security_result instead and as an alternative - src is a rarely used field unlikely to have data in it so we kind of hijack it. Neither is ideal of course. If the addition is too minor i would use src.security result. if the parser mixes up ALLOW and BLOCK for example or makes some error that will just hurt experience, I would go into the custom parser and fix it at the source. We lose updates this way unfortunately, so it's wise to submit a support ticket and request for that fix to be made in the parser itself and then revert back to default. We try to keep any custom parser changes to minimal and only necessary, and still have an extension for the cosmetic stuff to make it easy to upgrade it to default once big issues are handled.
Long story short - avoid repeated fields for extensions. It appears to work for additional though, which is good.