cisco_meraki: remove incorrect event.category:threat and event.type:indicator values

[efd6]

Proposed commit message

See title.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Fixes [Meraki] Incorrect 'threat' mappings #8493

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-11-22T06:16:02.312+0000

• Duration: 20 min 35 sec

Test stats 🧪

Test	Results
Failed	0
Passed	19
Skipped	0
Total	19

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[efd6]

I'm not entirely convinced that this is a correct category here, but on the basis of the contexts that I could find it seemed reasonable.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (2/2)	💚
Files	100.0% (9/9)	💚 3.281
Classes	100.0% (9/9)	💚 3.281
Methods	100.0% (67/67)	💚 7.171
Lines	98.463% (1153/1171)	👍 9.941
Conditionals	100.0% (0/0)	💚

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[kcreddy]

The current change LGTM 👍🏼
But there are 2 pipelines namely security.yml and idsalerts.yml that contains threat.indicator.* fields. Should we also remove them if they are not to be categorized as IoCs?

[efd6]

@P1llus What is your view on the references to threat.indicator.* in security.yml and idsalerts.yml?

[P1llus]

@P1llus What is your view on the references to threat.indicator.* in security.yml and idsalerts.yml?

From what I can see these are not IoC's, The sample pipeline test data was a bit weird, since both ids and security events are in the same testfile, so I had a hard time finding it first.

Since they are not IoC's then indeed the category should never be threat, and threat.indicator.* should simply be mapped to its common ecs field, like threat.indicator.file.name to file.name instead.
For ids-alert and security_event, if these are actual alerts, then we should also check that event.kind is alert rather than event.

There is also a weird test-generated.log-expected.json, which seems to be a golden file from when it was still an RSA package, since it does not have any value and do not have its raw file there anymore, lets remove it?

[efd6]

@P1llus PTAL

[P1llus]

LGTM, just 1 comment, feel free to provide the change (or none) that you find fits best 👍

[P1llus]

Can we ensure that all event types have at least one category and type? I think intrustion_dection and info is still a good fit. Or worst case it could be network and info?

[efd6]

They all already have event.type:["info"] and event.category:["network"] from here and here.

[P1llus]

Ah sorry, missed that one, LGTM 👍

[elasticmachine]

Package cisco_meraki - 1.20.1 containing this change is available at https://epr.elastic.co/search?package=cisco_meraki