[ 
https://issues.apache.org/jira/browse/METRON-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860129#comment-15860129
 ] 

ASF GitHub Bot commented on METRON-686:
---------------------------------------

Github user justinleet commented on the issue:

    https://github.com/apache/incubator-metron/pull/438
  
    I saw some odd behavior I think is unrelated to this PR itself while 
testing.
    
    I tried to remove the threat triage rule, messed up, fixed it, and then 
borked my conf variable.  After recovering I was able to successfully test (and 
run THREAT_TRIAGE_REMOVE without breaking conf).
    
    ```
    [Stellar]>>> conf
    {
      "enrichment" : {
        "fieldMap" : {
          "geo" : [ "ip_dst_addr", "ip_src_addr" ],
          "host" : [ "host" ],
          "stellar" : {
            "config" : {
              "is_alert" : "source.type == 'bro'"
            }
          }
        },
        "fieldToTypeMap" : { },
        "config" : { }
      },
      "threatIntel" : {
        "fieldMap" : {
          "hbaseThreatIntel" : [ "ip_src_addr", "ip_dst_addr" ]
        },
        "fieldToTypeMap" : {
          "ip_src_addr" : [ "malicious_ip" ],
          "ip_dst_addr" : [ "malicious_ip" ]
        },
        "config" : { },
        "triageConfig" : {
          "riskLevelRules" : [ {
            "name" : "Abnormal DNS Port",
            "rule" : "source.type == \"bro\" and protocol == \"dns\" and 
ip_dst_port != 53",
            "score" : 10.0
          } ],
          "aggregator" : "MAX",
          "aggregationConfig" : { }
        }
      },
      "configuration" : { }
    }
    [Stellar]>>> conf := THREAT_TRIAGE_REMOVE(conf, 'Abnormal DNS Port')
    [!] Unable to execute: java.lang.String cannot be cast to java.util.List
    org.apache.metron.common.dsl.ParseException: Unable to execute: 
java.lang.String cannot be cast to java.util.List
        at 
org.apache.metron.common.stellar.StellarCompiler.getResult(StellarCompiler.java:409)
        at 
org.apache.metron.common.stellar.BaseStellarProcessor.parse(BaseStellarProcessor.java:127)
        at 
org.apache.metron.common.stellar.shell.StellarExecutor.execute(StellarExecutor.java:275)
        at 
org.apache.metron.common.stellar.shell.StellarShell.executeStellar(StellarShell.java:373)
        at 
org.apache.metron.common.stellar.shell.StellarShell.handleStellar(StellarShell.java:276)
        at 
org.apache.metron.common.stellar.shell.StellarShell.execute(StellarShell.java:412)
        at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
        at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
    Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to 
java.util.List
        at 
org.apache.metron.management.ThreatTriageFunctions$RemoveStellarTransformation.apply(ThreatTriageFunctions.java:232)
        at 
org.apache.metron.common.stellar.StellarCompiler.exitTransformationFunc(StellarCompiler.java:267)
        at 
org.apache.metron.common.stellar.generated.StellarParser$TransformationFuncContext.exitRule(StellarParser.java:1689)
        at org.antlr.v4.runtime.Parser.triggerExitRuleEvent(Parser.java:422)
        at org.antlr.v4.runtime.Parser.exitRule(Parser.java:632)
        at 
org.apache.metron.common.stellar.generated.StellarParser.functions(StellarParser.java:1712)
        at 
org.apache.metron.common.stellar.generated.StellarParser.arithmetic_operands(StellarParser.java:1846)
        at 
org.apache.metron.common.stellar.generated.StellarParser.arithmetic_expr_mul(StellarParser.java:1609)
        at 
org.apache.metron.common.stellar.generated.StellarParser.arithmetic_expr(StellarParser.java:1469)
        at 
org.apache.metron.common.stellar.generated.StellarParser.transformation_expr(StellarParser.java:308)
        at 
org.apache.metron.common.stellar.generated.StellarParser.transformation(StellarParser.java:149)
        at 
org.apache.metron.common.stellar.BaseStellarProcessor.parse(BaseStellarProcessor.java:126)
        ... 8 more
    [Stellar]>>> conf := THREAT_TRIAGE_REMOVE(conf, ['Abnormal DNS Port'])
    [Stellar]>>> conf
    {
      "enrichment" : {
        "fieldMap" : { },
        "fieldToTypeMap" : { },
        "config" : { }
      },
      "threatIntel" : {
        "fieldMap" : { },
        "fieldToTypeMap" : { },
        "config" : { },
        "triageConfig" : {
          "riskLevelRules" : [ ],
          "aggregator" : "MAX",
          "aggregationConfig" : { }
        }
      },
      "configuration" : { }
    }
    ```


> 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)

Reply via email to