Ability to select and annotate a single instance of a technique spanning multiple tactics about attack-navigator HOT 4 CLOSED

@CollinFingar and I think that there are two possible ways to go about implementing this. Neither would require significantly more effort from an implementation standpoint, however there is a large difference in how the layer file format would be formatted. There is also a difference in how the techniques in the layer might be understood with regards to multi-tactic techniques, possibly biasing users to understand instances of techniques across multiple tactics as inherently similar or different.

Currently, the ATT&CK Navigator Layer file's techniques array has a single technique object for each technique, and techniques in multiple tactics refer to the same object. The changes to the layer file format are necessitated by the need to track annotations (score, comment, etc) by both technique and tactic.

For reference, this is how the technique objects in layer files are currently formatted:

{
    "techniqueID": "T####",
    "score": 32,
    "color": "",
    "comment": "some comment",
    "enabled": true
}

Method 1

In this method, the techniques array would be changed to contain an instances of a technique for each tactic the technique is contained in, and add a tactic field to track which tactic the instance of the technique is contained within.

For example, if the technique with the ID "T0001" were in tactics "tactic_a" and "tactic_b", you would have the following objects in the technique array:

"techniques": [
   {
      "techniqueID": "T0001",
      "tactic": "tactic_a",
      "score": 23,
      "color": "",
      "comment": "this technique is in tactic_a",
      "enabled": true,
   },
   {
      "techniqueID": "T0001",
      "tactic": "tactic_b",
      "score": 23,
      "color": "",
      "comment": "this technique is in tactic_b",
      "enabled": true,
   }
]

We feel that this method logically separates multi-tactic techniques because they would have different objects in the array. Multi-tactic techniques might be understood as inherently dissimilar since they do not share the same object.

Advantages

The major advantage of this method is that it is not a major change from the current layer format on a per-technique basis. Some programs or scripts may have an easier time adapting to this method if they are able to adapt to the duplication of techniques in the techniques array.

Disadvantages

A technique array which contains essentially duplicative objects may be unintuitive, especially if the user does not edit instances of techniques. Techniques in the array could no longer be uniquely identified by their techniqueID field, rather, the joining of their techniqueID and tactic would be the new UID. This could mean major changes are required for some programs or scripts which generate or parse layer files.

Backwards compatibility

Uploading a technique without the tactic field would copy the annotations to all instances of that technique (all techniques in the array with the same techniqueID).

Method 2

In this method, the techniques array would still have unique technique objects. The techniqueID field could still be used as a unique identifier. Each technique object would contain annotations for each tactic in which it is contained.

For example, if the technique with the ID "T0001" were in tactics "tactic_a" and "tactic_b", you would have the following technique object in the technique array:

{
   "techniqueID": "T0001",
   "annotations": {
      "tactic_a": {
         "score": 23,
         "color": "",
         "comment": "this technique is in tactic_a",
         "enabled": true
      },
      "tactic_b": {
         "score": 23,
         "color": "",
         "comment": "this technique is in tactic_b",
         "enabled": true
      }
   }
}

We feel that this method promotes the understanding that multi-tactic techniques are inherently similar since they would share the same base object, and that their annotations are the main difference in how they should be understood to behave between tactics.

Advantages

In this method, the techniques array would have a single object for each technique, and thus the techniqueID field could still be used as a unique identifier. Some programs or scripts may have an easier time adapting to this method if they are more adaptable to how they parse technique annotations.

Disadvantages

This is a major change to how techniques are formatted in the array. Programs or scripts which are inflexible in how they parse technique annotations could major changes to account for the new annotations format.

Backwards compatibility

Uploading a layer file with the old style of annotations (not annotations by tactic) would copy those annotations to every tactic of the technique.

from attack-navigator.

Method 1 seems much more intuitive to me and how I've been programmatically generating layer files.

Would it be possible to allow users to omit the tactic property, even if they're generating v2 layer files, and have it implicitly apply that technique to all tactics similar to how it works for backwards compatibility? That way people who don't care about the tactic distinctions can still generate layers as they do now (no cost to upgrade), and those who need the extra functionality can just add that property.

from attack-navigator.

@johnwunder Yes, as noted in the backwards compatibility section of method 1,

Uploading a technique without the tactic field would copy the annotations to all instances of that technique (all techniques in the array with the same techniqueID).

from attack-navigator.

Pushed to develop along with documentation on selecting single instances.

from attack-navigator.