You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "Jon Zeolla (JIRA)" <ji...@apache.org> on 2016/11/18 16:18:00 UTC

[jira] [Comment Edited] (METRON-572) Add API ad-hoc enrichment

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

Jon Zeolla edited comment on METRON-572 at 11/18/16 4:17 PM:
-------------------------------------------------------------

That would give me historical log information regarding those IPs, what I'm looking for is the current internal state of Metron regarding an enrichable field.  It would both be helpful for troubleshooting and during incident triage.  To further illustrate, here are some offhand use cases:
1. SOC Analyst is working with the search layer but sees characteristics of an issue with enrichment.  They escalate to the platform engineer, which would then take examples that the SOC Analyst provided and uses the API to determine if it's a persistent or transient issue (as opposed to replaying or pushing fabricated data into a prod search environment).  Additionally, while remediating the issue it would be helpful for the platform engineer to test their alterations easily.  This assumes that there may not be a test/dev environment, or that test/dev is not exhibiting the same behavior as prod.
2. SOC Analyst is working on a large, time sensitive incident.  They have a long list of potentially compromised machines and would like to quickly retrieve what is currently known about that list of machines in order to prioritize remediation and forensics.  For example, there may be enrichment actions regarding a system's data sensitivity and criticality of known assets, and querying the search layer would be excessively onerous on the systems (especially when there is low or no volume to search against).
3. Enrichments may exist for a system which is not currently sending logs into Metron, nor are you getting network information regarding the system, so there would be nothing to find in the search tier.


was (Author: zeolla@gmail.com):
That would give me historical log information regarding those IPs, what I'm looking for is the current internal state of Metron regarding an enrichable field.  It would both be helpful for troubleshooting and during incident triage.  To further illustrate, here are some offhand use cases:
(1) SOC Analyst is working with the search layer but sees characteristics of an issue with enrichment.  They escalate to the platform engineer, which would then take examples that the SOC Analyst provided and uses the API to determine if it's a persistent or transient issue (as opposed to replaying or pushing fabricated data into a prod search environment).  Additionally, while remediating the issue it would be helpful for the platform engineer to test their alterations easily.  This assumes that there may not be a test/dev environment, or that test/dev is not exhibiting the same behavior as prod.
(2) SOC Analyst is working on a large, time sensitive incident.  They have a long list of potentially compromised machines and would like to quickly retrieve what is currently known about that list of machines in order to prioritize remediation and forensics.  For example, there may be enrichment actions regarding a system's data sensitivity and criticality of known assets, and querying the search layer would be excessively onerous on the systems (especially when there is low or no volume to search against).
(3) Enrichments may exist for a system which is not currently sending logs into Metron, nor are you getting network information regarding the system, so there would be nothing to find in the search tier.

> Add API ad-hoc enrichment
> -------------------------
>
>                 Key: METRON-572
>                 URL: https://issues.apache.org/jira/browse/METRON-572
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Jon Zeolla
>            Priority: Minor
>
> In the API, given { "ip_src_addr": [ "1.1.1.1", "2.2.2.2" ] }, provide all context the system currently has regarding the input by processing a configurable list of enrichments, set in zk, then responding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)