[
https://issues.apache.org/jira/browse/METRON-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037246#comment-16037246
]
Otto Fowler commented on METRON-984:
------------------------------------
Yeah, that is what I'm thinking has to happen.
What comes to mind for me as a concern: you don't know what may be in the
field -> so you have to run it through multiple decoder's - at least at first.
This is at the lowest, most naive level. You end up adorning the message with
multiple 'decoded' fields, which you have no idea if they have gobble gook in
them or not.
But these are low level functions. In the future, what I would think would be
a metron rules engine would have rules for specific things and 'know' what to
look for in certain fields, because the rule may be targeted.
Does that make sense?
> Create Stellar Decoding Functions
> ---------------------------------
>
> Key: METRON-984
> URL: https://issues.apache.org/jira/browse/METRON-984
> Project: Metron
> Issue Type: Improvement
> Reporter: Jon Zeolla
> Assignee: Otto Fowler
>
> It is rather commonplace for malicious actors to obfuscate exploits or data
> transfers using encoding. In order to identify and prioritize responses to
> (or automatically mitigate) those attacks during threat triage we should have
> a method for decoding in Stellar. Some initial thoughts would be to handle
> percent/URL encoding, base64, base32, base16/hex, HTML encoding, etc.
> I would expect that something like DECODE(something, encoding_type,
> optional_failure_mode) would return the contents of field "something" after
> attempting to decode it via "encoding_type". If decoding fails,
> optional_failure_mode would indicate whether or not to fail the message and
> send it to the error topology, or to simply return the contents of the
> original field "something" (in this example).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
