Return matched.atomic value from indicator

[nkhristinin]

Summary

Switched back to put into matched.atomic value from threat indicator, not source event.

How to reproduce the bug:

PUT /threat-index
{
  "mappings": {
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "ip_range": {
        "type": "ip_range"
      }
    }
  }
}

PUT /source-index
{
  "mappings": {
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "ip": {
        "type": "ip"
      }
    }
  }
}

POST threat-index/_doc
{
  "@timestamp": ${timestamp},
  "ip_range": "127.0.0.1/30"
}

POST source-index/_doc 
{
  "@timestamp": ${timestamp},
  "ip": "127.0.0.2"
}

Create a rule like

Then you should have alert with some threat enrichments which has matched.atomic - 127.0.0.2 which is a wrong:

If you switch to this PR branch and send one more alert like

POST source-index/_doc 
{
  "@timestamp": ${timestamp},
  "ip": "127.0.0.3"
}

You should see matched.atomic value as 127.0.0.1/30

Checklist

Delete any items that are not applicable to this PR.

• [x ] Unit or functional tests were updated or added to match the most common scenarios

[nkhristinin]

@elasticmachine merge upstream

[nkhristinin]

@elasticmachine merge upstream

[nkhristinin]

@elasticmachine merge upstream

[nkhristinin]

@elasticmachine merge upstream

[nkhristinin]

@elasticmachine merge upstream

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: b26c7f4
• Interpreting CI Failures
• Storybooks Preview
• Webpack Bundle Analyzer

Failed CI Steps

• Build and Deploy to Cloud

Metrics [docs]

✅ unchanged

History

• 💔 Build #48428 failed ac4c51f
• 💔 Build #48355 failed 9c46270
• 💔 Build #48298 failed bef1280
• 💔 Build #48288 failed 92e7311
• 💚 Build #46132 succeeded 6cd6642

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[rylnd]

This one got lost in the shuffle, I think... If we can fix the file conflicts I think this will be good to go! Just let me know and I can approve.

[rylnd]

If we now have two different values for threatListConfig, can we give them distinguishing names? It's not obvious from this level how the results of getThreatListConfig() differ from the manually mapped version.

[rylnd]

A few unit tests showing how this works would be helpful!