"Select All" techniques disregard filters in place

[Fenr1r-g]

As the title suggests, the current version of Navigator's function to "Select all techniques" disregards the filters set in place. For example, the default filters when loading navigator include ATT&CK with Linux, Windows, and MacOS selected (no pre-att&ck, cloud, etc), however, "select all" selects all techniques, including those filtered out.

This can make any JSONs that are exported needlessly long as those techniques that are not in view are now tagged with colors, scores, comments, etc. It also makes modeling and charting of results...more complicated.

[isaisabel]

Hi @Fenr1r-g,

Thank you for reaching out. This behavior (selections applying to techniques that are hidden from view) actually extends beyond just "select all" to all interfaces where broad/indirect selections occur:

• Invert selection
• Multi-select
• Select annotated/unannotated
• Search

I wouldn't want to apply a "hidden techniques cannot be selected" rule without applying it equally across these different possible cases. And I think, especially in the case of multiselect, that there is a strong case that even hidden items should get annotated. For example, a user selecting the techniques of a group to apply an annotation may not realize that one of the techniques of that group is in a cloud platform (which are hidden by default). Should that technique be omitted from the selection because the cloud platform is hidden? In my opinion it probably shouldn't because the group maps to the technique regardless of how the user has set up their view.

I can think of two other ways to approach this which may work:

1. I guess a possible other way to approach this would be to limit the "don't select hidden stuff" rule to only techniques that have been disabled and hidden. Disabled and visible techniques should still be selectable en masse, because users will likely want to use selection functionalities to select large numbers of disabled techniques for re-enabling. But hidden and disabled could be excluded from selections without issue.
2. Add an extra preference to the layer download interface, "only download annotations on visible techniques," which would help reduce the clutter you mentioned. We'd have to think about the approach for disabled/hidden techniques however, since those would likely still need annotations.

I'm curious to hear your thoughts on this. I definitely understand and agree with what you're saying, but I worry that there are additional repercussions of simply excluding selections from techniques not in the current view.

[Fenr1r-g]

Apologies for the delayed response, complicated IRL move.

I think of the two possibilities you've mentioned, option two works best. I think one way of mitigating the situation where a disabled/hidden technique has an annotation of some sort (comment/score/metadata) is a quick check against whether a hidden technique actually has an annotation, and if it does, then perhaps a user warning prompt?

for p in hiddentechniques: if p["comment"] != "" print(f"Your layer includes hidden techniques that contains a comment/score/metadata. Would you prefer to have this in your final JSON?")

That way, if the user wasn't aware of this, they have an opportunity to see what those comments are. Just my thoughts and please excuse the python/pseudocode.

[Fenr1r-g]

I also have no idea why that last sentance is bolded...I promise I'm not yelling that

[isaisabel]

Yeah that's a good idea. The new download/export feature could look something like this maybe (though this honestly needs a lot of refinement, probably the lefthand side should be marked "save" and the righthand side marked "export"):

Basically a consolidation of the three different export buttons (json, excel, svg) into a single organized dropdown.

[Fenr1r-g]

I think that makes sense from a UX perspective as well: one consolidated place for output.

[clemiller]

Changes are staged on develop and will be included in the next Navigator release.