[Security Solution] Incorrect rule count on MITRE coverage tactic cell

[approksiu]

Describe the bug:
Rule is duplicated in the mitre att&ck page cell

Kibana/Elasticsearch Stack version:
8.10.2, 8.10.3

Server OS version:

Browser and Browser OS versions:

Elastic Endpoint version:

Original install method (e.g. download page, yum, from source, etc.):

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

Steps to reproduce:

1. Install all rules, enable them
2. Go to MITRE ATT&CK page
3. Search for T1546.015 (as an example)
4. Check rule counts on the tactic tile for "Persistance" and "Privilege Escalation"

Current behavior:
The rule count is 1 on Persistance, and 0 on Privilege Escalation.

Expected behavior:
The rule count is 1 on Persistance, and 1 on Privilege Escalation.

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context (logs, chat logs, magical formulas, etc.):

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

@dplumlee Let's sync and see if we could quickly fix this in 8.11

[maximpn]

@dplumlee @banderror I checked this behavior locally. It's Component Object Model Hijacking prebuilt rule. According to the docs it has the following categories

Tactic:

Name: Persistence
ID: TA0003
Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:

Name: Event Triggered Execution
ID: T1546
Reference URL: https://attack.mitre.org/techniques/T1546/
Sub-technique:

Name: Component Object Model Hijacking
ID: T1546.015
Reference URL: https://attack.mitre.org/techniques/T1546/015/

so we should expect it in Persistence, Event Triggered Execution and Component Object Model Hijacking cards. But for some reason it's in Persistence, listed twice in Event Triggered Execution

and not listed at al in Component Object Model Hijacking.

The API endpoint returns the correct result

{
    "coverage": {
        "TA0003": [
            "3e8736a0-4718-11ee-a876-8955b5f07a55"
        ],
        "T1546": [
            "3e8736a0-4718-11ee-a876-8955b5f07a55"
        ],
        "T1546.015": [
            "3e8736a0-4718-11ee-a876-8955b5f07a55"
        ]
    },
    "unmapped_rule_ids": [],
    "rules_data": {
        "3e8736a0-4718-11ee-a876-8955b5f07a55": {
            "name": "Component Object Model Hijacking",
            "activity": "disabled"
        }
    }
}

so I'd say it's a purely UI bug.

@approksiu I'm curious from where did Privilege Escalation come from?

[approksiu]

@maximpn

and not listed at al in Component Object Model Hijacking.

The Component Object Model Hijacking technique has moved as subtechnique under Event triggered Execution (T1546) technique, so that rule should not show up there. The old techniques showing up on the page issue has been fixed.

I'm curious from where did Privilege Escalation come from?

While the rule is not explicitly mapped to Privilege Escalation tactic, it does show up on the Event triggered Execution tile under Privilege Escalation tactic.

[maximpn]

@approksiu

The Component Object Model Hijacking technique has moved as subtechnique under Event triggered Execution (T1546) technique, so that rule should not show up there. The old techniques showing up on the page issue has been fixed.

Interesting, there are two cards Component Object Model Hijacking with id T1546.015

the rule has a sub-technique assigned

so I'd expect the rule to appear in these cards.

My point is that UI doesn't correspond to API response and the rule is listed twice in one card. It's definitely a bug.

While the rule is not explicitly mapped to Privilege Escalation tactic, it does show up on the Event triggered Execution tile under Privilege Escalation tactic.

This is how the algorithm works right now. It just maps existing tactics/techniques/sub-techniques to rules based on the coverage params. If something isn't specified it just gets skipped. It can be fixed by enriching the parent category when building the rules coverage mapping.

[banderror]

My point is that UI doesn't correspond to API response and the rule is listed twice in one card. It's definitely a bug.

++ Most definitely, there's a bug in the code that processes the API response on the FE side before showing the grid. The #167917 PR doesn't fix this. TY @maximpn for the investigation!

[maximpn]

@dplumlee we should have scenarios in the test plan covering behavior described in this ticket. In particular UI/backend properly handles properly techniques/sub-techniques encountered in different tactics. As far as I remember we don't have such scenarios described right now.

[banderror]

@vgomez-el Fixed by #169708 and should be available in the last 8.11.0 BC 8.11.1 and the first BC for this patch release. Context: #169708 (comment)

[banderror]

Closing for the same reason as #167929 (comment)

[ghost]

hi @approksiu

we have validated this issue on 8.11.2 and on filtering data using "T1546.015" on mittre dashboard with all rules enabled we are getting correct rule counts on the tactic tile for "Persistance" and "Privilege Escalation" ✔️

Build details:

Version: 8.11.2
Commit: 92746356b61c3e3ac62b6d7045727f8d737fa4b5
Build:68299

Screen-Shot

Hence we are closing this issue and adding "QA:Validated" tag to it.

thanks !!