Extension of RA/RPs to facilitate future IDs

[pjabes]

Presently, the namespace for both Response Actions and Response Plans facilitates up to 99 unique items. There has been some discussion within the ATC Slack about whether that should be increased given the large variety of different work types that could occur across.

By way of an example - If the last Identification (Stage), File (Category) was 2399 and you wanted to add another one, you can not use 2400 without a clash (and violating the naming convention).

[xofolowski]

Another motivation for increased ID namespaces could be custom additions that are not deemed valuable for the ATC community. Imagine I wanted to add an RA that is super specific for my environment: I could do so and just add it with a (currently unused) 4-Digit ID to my fork of the RE&CT repository. However, chances are big that the ID I chose will clash with the ID of another RA that's going to be added to the official repository in the future. If the ID was 5-Digit, it would be possible to define the upper end of the range as "user reserved"; e.g. IDs xx900 - xx999 could officially be excluded from the official RE&CT repository.

[yugoslavskiy]

Hello @pjabes , @xofolowski! Thank you guys for creating this ticket and your proposals.

We've been thinking a lot about IDs' future and all the points that you've brought up in the ATC Slack threads.

Let me comment on the topics separately:

If the ID was 5-Digit, it would be possible to define the upper end of the range as "user reserved"; e.g. IDs xx900 - xx999

Your idea is great. I would only adjust it a bit. Let me explain. There is another point to consider, rather than creating new custom RAs — overwriting original RAs with internal ones. I believe that there is should be YXXXX IDs, where:

• Y — switch for analytics source i,e. 0 - original public framework's data, 1 - internal SOC, 2 - external SOC, 3 - etc; 9 custom sources, as we will allocate only one of them (0) and the rest (1-9) will be up to our users.
• XXXX — original IDs that reflect Response Stage and RA Category

It's important to provide users with the ability to create user-defined RAs with the same IDs. I believe that we can implement a merging mechanism with the option to define a way the analytics will be handled (exported) in case of the matching IDs:

• replace original RA/RP with the user-defined one
• keep both (create a separate one with the same ID)
• something else?

We could make it configurable in the config file (so defined globally for all the analytics) or in a specific RA/RP.

Also, here is how we are going to avoid clashes (2399 + 1):

1. Group RAs to make them more high-level. Let use the RA3101-3111 (Containment stage, Network category) as an example for such grouping:

• RA3101: Block external IP address
• RA3102: Block internal IP address
• RA3103: Block external domain
• RA3104: Block internal domain
• RA3105: Block external URL
• RA3106: Block internal URL
• RA3107: Block port external communication
• RA3108: Block port internal communication
• RA3109: Block user external communication
• RA3110: Block user internal communication
• RA3111: Block data transferring by content pattern

They all could be grouped into something like:

• RA3101: Block internal resource from communication with external resource
• RA3102: Block external resource from communicating with internal resource
• RA3103: Block internal resource from communicating with internal resource

And that's it. What is the resource exactly is (user, IP address, domain) as well as how exactly it could be done (by port, by user, URL or protocol etc) could be defined on the sub-RA level:

2. Move to the more detailed description in sub-RAs (ATT&CK way), i.e. 2390.001 (+1000 options for high-level RA). I believe that this is the future. This is the way how we could connect with ATT&CK on the RA level. I will describe our proposals in the https://github.com/atc-project/atc-react/issues/291 soon.

There is another point of doing that — we will move to the new version of the ATT&CK Navigator, and later would be able to use ATT&CK website source code to create new (better) web UI for RE&CT. To do that, we need to:

• Improve our STIX export to have a fully compatible schema (the website is generated out of ATT&CK STIX files)
• Fork ATT&CK website repo and adjust the configs to utilize our STIX file/images/etc

---

This way we will have lots of free ID numbers for users to utilize. We also will provide them with the option to keep all data even in case of an intersection. What do you guys think?

[yugoslavskiy]

sorry, forgot one point — "user reserved" IDs could be also applied. How about Y8000-Y9999? 1-6 are existing Response Stages. We could leave 0 and 7 reserved for us, and 8-9 — for users. what do you guys think?

[xofolowski]

Hi @yugoslavskiy, sorry for the late response - last weeks kept me quite busy. Your proposal looks quite sensible in my eyes.

However, in general, what is the advantage in your opinion of having a somehow schemed numbering for RAs/RPs over just using UUIDs? Any information that is in the numbering scheme right now could just be put in RA/RP metadata (as it is already partly done, e.g. for the response phase). Having just UUIDs one could

• reference RAs from RP definitions
• avoid any numbering clashes
• introduce inheritance -> If there was already an RA "UUID-XX" in the official repository, I could write a custom RA "UUID-YY" that inherits all data from UUID-XX except for the fields explicitly defined by myself. Doing so, even my self-written RAs could benefit from upstream changes

Mapping to ATT&CK techniques / subtechniques could be achieved by referencing either the respective IDs directly, or maybe even via the techniques' STIX-UUIDs.

What do you think?