How to implement RE&CT in my organization

[dsvetlov]

The use cases and implementation process for this framework are not clear. Kindly ask everybody who is concerned to discuss it.

From my point of view. These "tactics and technics" are "theoretical" or very high-level to be actionable for a wide audience. Hence they should be clarified and detailed for each organization.

Hence atc-react could be used as a skeleton of RA catalog in Atomic Threat Coverage. But each RA should be modified for certain needs and processes of an organization.

These are my thoughts about atc-react and it's use cases. I think that @yugoslavskiy and @mrblacyk did a great job and we need to think about how to make this data more actionable.

Please share your thoughts and opinions, because I'm an active ATC user and want to know how other companies use it.

[sn0w0tter]

Hi @dsvetlov

We agree with your opinion. The problem which we were facing was to not go too deeply in response actions as those varies in every environment, but at the same time not be too high level (Preparation: Prepare for incident ;). For example we suggest some of the tools which we tested and which worked well for us (like a munpack in RA_2205_extract_observables_from_email_message) but a lot of RAs are dependable on what's inside environment. So to keep it adjustable we need to stay high level, however we believe that once skeleton will be ready we (and community) can add more detailed descriptions of options. It's still in alpha phase, most probably in future we will go deeper in similar fashion as ATT&CK is currently doing with introduction of sub-techniques.

[yugoslavskiy]

Hi @dsvetlov!

[...] each RA should be modified for certain needs and processes of an organization [...]

You are absolutely right. We developed Response Actions in the way to:

1. be universal. Which means, applicable for any organization. At the same time, it means that it has to be high-level. And the hardest part here is the definition of the abstraction level.
2. be system and method-agnostic. The RAs doesn't include any specific Mitigation System/Data Needed/etc in the name/description/body. These things are listed in the requirements field. It makes RAs extendable by the ability to map these entities to it.
3. include notes for a user. It is an extract of experience. They are one of the most valuable things here. We will move forward the same way and hope that community will support it, and contribute to these notes.

Let me go through the operationalization process step by step:

1. Download atc-react repo
2. Update (or create your own) Response Actions/Response Stages/Response Playbooks
3. Use the main.py to export the analytics to preferable format
4. That's it

[...] we need to think about how to make this data more actionable [...]

That's supposed to be done on the user side. There are many unique requirements, internal specifics, systems and methods to execute a particular Response Action in an organization.

So we better focus on the Response Actions development (the variety) in the way they are right now, rather than going deeper in some specifics. We also need to integrate Data Needed and Mitigation Systems to provide analytics about the value of one system/data in comparison to the others.

We believe that it would be more valuable for the community.

[pjabes]

This specific topic has been on my mind since first introduction to the project, and I'd just like to share some thoughts on how I think organizations could leverage ATC-RE&CT.

Nirvana-state usage of RE&CT.

• A RE&CT should be leveraged as the oracle of truth and work product of the incident response team. IR teams should be directly responsible for customizing the existing RE&CT Response Actions (RAs) to match the individual needs of the organisation as previously mentioned, as well as being directly responsible for weaving these Response Plans (RPs).
• IR Analysts should interface with Response Plans within their alert ticketing system and leverage these as guidelines for a minimum "what-to-do" during the alert. IR Analysts should also be encouraged to not leverage RPs as checklists, but to think widely and critically about what other Response Actions could be completed (whether they are described here or not). IR Analysts should feed this information back into the ticketing system which should be periodically reviewed to ensure RPs are kept up-to-date and are comprehensive.
• SOC Managers/Execs should leverage a RE&CT Navigator with their teams current people/process/technology coverage. This will help them to understand the gaps in their current operations and drive future investment. For example; it may be seen that a technology products enables Cyber Defence teams to leverage a critical capability "RA1311: Collect File" that is otherwise missing in a separate technology product.
• SOAR teams should be leveraging the IR team's work products to build out automatic response actions and response plans.
• Organisations should be able to convene during major incidents to review their response plans for thoroughness.
• Organisations should feedback generic Response Plans/Response Actions to open source (and sponsor the project!) 😄

From a practical perspective, I'm trying to push an organization I've worked with in the past towards RE&CT for SOAR.

• Having a shared (and documented) language to describe playbooks drastically reduces SOAR development costs.
• Response Actions mash well with the concept of The Dry Principle.
• With integration into ticketing systems, I can perform analysis to see what Response Actions are categorically the most expensive (or repetitive) for an organisation to undertake. This ensures that we are picking the low hanging fruit.

Would love to hear how others are leveraging RE&CT in their organization or your views on how it could be leveraged.