[
https://issues.apache.org/jira/browse/METRON-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878706#comment-15878706
]
ASF GitHub Bot commented on METRON-686:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/438
So assuming we put aside the issue of flattening the data per METRON-735,
what should be the go-forward for this PR? I outlined two options above.
Please share your opinions on those options.
> (1) Assume that any indexer that cannot handle complex types is currently
broken.
>
> Since the assumption is that the Solr indexer is 'broke', then we can
move forward and commit this PR (pending further review) BEFORE addressing the
Solr indexer.
> I will then create a JIRA to test and fix any indexer that cannot handle
complex types. Based on the discussion here, I am assuming this includes the
Solr indexer.
>
> (2) Assume that we need to live in our current box.
>
> I will update this PR to flatten the data to make the Solr Indexer happy.
> I will then create a JIRA to fix the Solr Indexer.
> After the Solr Indexer is fixed, I will then create another PR to return
threat triage to its current state (using a complex type instead of flattening.)
Personally I am +1 on option 1, but either works for me. Maybe there is a
better approach that I am not thinking of.
> Record Rule Set that Fired During Threat Triage
> -----------------------------------------------
>
> Key: METRON-686
> URL: https://issues.apache.org/jira/browse/METRON-686
> Project: Metron
> Issue Type: Improvement
> Reporter: Nick Allen
> Assignee: Nick Allen
>
> h3. Problem
> There is little transparency into the Threat Triage process itself. When
> Threat Triage runs, all I get is a score. I don't know how that score was
> arrived at, which rules were triggered, and the specific values that caused a
> rule to trigger.
> More specifically, there is no way to generate a message that looks like "The
> host 'powned.svr.bank.com' has '230' inbound flows, exceeding the threshold
> of '202'". This makes it difficult for an analyst to action the alert.
> h3. Proposed Solution
> To improve the transparency of the Threat Triage process, I am proposing
> these enhancements.
> (1) Threat Triage should attach to each message all of the rules that fired
> in addition to the total calculated threat triage score.
> (2) Threat Triage should allow a custom message to be generated for each
> rule. The custom message would allow for some form of string interpolation
> so that I can add specific values from each message to the generated alert.
> We could allow this in one or both of the new fields that Casey just added,
> name and comment.
> (3) The specific method of string interpolation will be implemented under a
> separate issue.
> h3. Example
> (1) In this example, we have a telemetry message with a field called 'value'
> that we need to monitor. In Enrichment, I calculate some sort of value
> threshold, over which an alert should be generated.
> (2) In Threat Triage, I use the calculated value threshold to alert on any
> message that has a value exceeding this threshold.
> (3) By leveraging a new field called 'reason', I can embed values from the
> message, like the hostname, value, and value threshold, into the alert
> produced by Threat Triage.
> {code}
> "triageConfig" : {
> "riskLevelRules" : [ {
> "name" : "Abnormal DNS Port",
> "rule" : "source.type == 'bro' and protocol == 'dns' and ip_dst_port
> != 53",
> "score" : 10.0,
> "reason" : "FORMAT('Abnormal DNS Port: expected: 53, found: %s:%d',
> ip_dst_addr, ip_dst_port)"
> } ],
> "aggregator" : "MAX",
> "aggregationConfig" : { }
> }
> {code}
> (4) The Threat Triage process today would add only the total calculated score.
> {code}
> "threat.triage.level": 10.0
> {code}
> With this proposal, Threat Triage would add the following to the message.
> {code}
> "threat.triage.level":{
> "score":10.0,
> "rules":[
> {
> "name":"Abnormal DNS Port",
> "comment":null
> "score":10.0,
> "reason":"Abnormal DNS Port: expected: 53, found: 224.0.0.251:5353",
> }
> ]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
