[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 Ok, I'm +1 on this pending successful travis. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 Ok, I flattened the threat score with the latest commit. The PR description has also been updated to match current state. Please take a gander. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 Sounds good, looks like there are more votes for option 2. I'll go that route. Gracias! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user ottobackwards commented on the issue: https://github.com/apache/incubator-metron/pull/438 I think what we are saying is 1. I think that is the best way to move forward. Just make sure that this commit isn't merged into an RC for 0.3.1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 @ottobackwards @cestella @justinleet - Let me know what you guys think on my previous comment about how to move forward on this PR. I think we have a rough outline of the "flattening" stuff, but how should we move forward on this PR specifically. See options outlined in my previous comment. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
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. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user ottobackwards commented on the issue: https://github.com/apache/incubator-metron/pull/438 I commented on 735 so it wins. #settled --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 rgr, deleting 736 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user ottobackwards commented on the issue: https://github.com/apache/incubator-metron/pull/438 let me know which one to comment on! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 Ha... oops. Yep, we agree. Add your commentary to METRON-735. You're suggesting a specific implementation, which is good. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 Ok, it appears that I tramped you, @nickwallen Our JIRAs seem to be suggesting the same thing, am I right? If you say so, I'll delete mine. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 Created [METRON-735](https://issues.apache.org/jira/browse/METRON-735), in case this idea gains wider support from the community. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 I'm of the opinion that the flattening should be writer-specific and that should be a function of the writer config with the default to be specified by the writer implementation. This way we can have our cake and eat it too. Also, we could ALREADY be in a situation where messages aren't flat (imagine a situation where a stellar function returns a map or a list and it get assigned to a field). The *only* safe way to do this is to enforce it at the writer, IMO. This is one of the stated benefits to extracting writer configs into their own structures. Regarding existing conventions, this one was around when I joined the project. I might be wrong, but it was an early convention. The reasoning, as I recall, was multi-fold: * Solr didn't handle it * Interacting with complex structures was deemed to be difficult * Indexing nested structures had some performance implications As to how to move forward, my suggestion is conform to convention for this JIRA and flatten. I created a JIRA to track the flattening effort at [METRON-736](https://issues.apache.org/jira/browse/METRON-736) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 @ottobackwards Yep, good call out. We should address the JSON mapper as you described also. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user ottobackwards commented on the issue: https://github.com/apache/incubator-metron/pull/438 That makes sense, thanks for the explanation. I am +1 for having SOLR specific flattening, although documenting well needs to be a priority. Also, if we do this, please log a jira that the flattening in the json mapper needs to be optional by configuration --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 > if you look at the JSONMapParser, Casey and I implemented a flattener... @ottobackwards Thanks for pointing that out. If we end up going with option 2, I will try and reuse that flattener. > I am more confused about there being non flattened things going through actually. Even if I use a parser that generates only flattened data, I could create an enrichment (like using `GEO_GET`) that appends non-flat data to a message. Thus we have non-flat data coursing through the veins of Metron. ;) I think the original idea of flattening data was because one of our Indexers could not handle non-flat, complex data types. At the time, we just decided, well don't create any non-flat data. But now, since we have a completely 'programmable' system, I don't think it is safe to assume that the data will always be non-flat. A user could create their own Stellar function to use during enrichment. Should we force on them the burden of flattening the data? It makes way more sense in my mind, to make the indexer transform the data however it needs to , to correctly index the data. If the current issue is with the Solr Indexer, then we should fix that to flatten any data that it needs to. There would be one touch point to address this issue rather than many. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user ottobackwards commented on the issue: https://github.com/apache/incubator-metron/pull/438 Nick - if you look at the JSONMapParser, Casey and I implemented a flattener that you would use for this. So, all of our json stuff from that _was_ already flattened. I am more confused about there being *non* flattened things going through actually. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 I really could use some opinions on the go-forward here. I see two 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.) I think those are the best options forward. Let me know if there is another alternative. Thanks all! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user nickwallen commented on the issue: https://github.com/apache/incubator-metron/pull/438 Bump? Haven't received feedback on my last comments. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user james-sirota commented on the issue: https://github.com/apache/incubator-metron/pull/438 I think a better approach is to bake in an enforcement layer within Metron to only allow flat maps (key-value pairs where the value cannot be a complex object). You would enforce that in the parsers as well as enrichers. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Could you re-use the jsonmap parser stuff? On February 10, 2017 at 13:58:54, cestella (g...@git.apache.org) wrote: Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 It occurs to me that one thing we might consider going forward is to flatten the map upon writing to the index. We could configure the message flattening as a capability on a per-writer basis. This would let us adjust the message representation to the index. We already have a hook to transform the messages (the `FieldNameConverter` class). That being said, we'd have to have different hooks than just `FieldNameConverter`, which just operates on field names. Instead, you'd need a `FieldValueConverter` as well. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 It occurs to me that one thing we might consider going forward is to flatten the map upon writing to the index. We could configure the message flattening as a capability on a per-writer basis. This would let us adjust the message representation to the index. We already have a hook to transform the messages (the `FieldNameConverter` class). That being said, we'd have to have different hooks than just `FieldNameConverter`, which just operates on field names. Instead, you'd need a `FieldValueConverter` as well. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user cestella commented on the issue: https://github.com/apache/incubator-metron/pull/438 I think the only thing that's concerning me here is that we have avoided complex types in values in the past. I believe it had to do with ES performance and the fact that not all indexes (i.e. Solr) support it. I'd suggest flattening that `threat.triage.level` map into * `threat.triage.level.score` * `threat.triage.level.name` * `threat.triage.level.comment` * `threat.triage.level.reason` Or, alternatively, just drop the level and make it `threat.triage.score`, etc. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user justinleet commented on the issue: https://github.com/apache/incubator-metron/pull/438 +1, Everything looks good. As noted above, both the issue I had and the review comment were addressed by adding new Jiras and aren't needed here. Thanks a lot, Nick. This is really helpful. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user justinleet commented on the issue: https://github.com/apache/incubator-metron/pull/438 After talking with Casey, it's an issue with StellarShell, not this PR. I'll make a ticket and get it done. So feel free to ignore this issue, @nickwallen --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
Github user justinleet commented on the issue:
https://github.com/apache/incubator-metron/pull/438
Seems like THREAT_TRIAGE_REMOVE just behaves really badly
```
[Stellar]>>> conf := THREAT_TRIAGE_ADD(conf, [triage])
[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
[Stellar]>>> conf
[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" : { }
}
```
I'd have to check if the same thing happens on master.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-metron issue #438: METRON-686 Record Rule Set that Fired During Th...
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" : { }
}
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
