valitydev/atomic-threat-coverage
14
0
Fork 0
mirror of https://github.com/valitydev/atomic-threat-coverage.git synced 2024-11-06 01:25:21 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

uploaded RU and PL versions; updated main README

Browse Source
This commit is contained in:
yugoslavskiy 2019-01-07 01:38:37 +01:00
parent 839ef59160
commit a3e7c47d30
4 changed files with 580 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
README.md
View File

@ -1,11 +1,13 @@
🇷🇺 [Русская версия](README_RU.md) | 🇵🇱 [Polska wersja](README_PL.md)
# Atomic Threat Coverage
Automatically generated knowledge base of analytics designed to cover threats based on MITRE's ATT&CK.
Automatically generated knowledge base of analytics designed to combat threats based on MITRE's ATT&CK.
![](images/atc_description_v01.png)
![](images/logo_v1.png)
<!-- ![](images/atc_description_v01.png) -->
Atomic Threat Coverage is tool which allows you to automatically generate knowledge base of analytics, designed to cover threats (based on the [MITRE ATT&CK](https://attack.mitre.org/) adversary model) from Detection, Response, Mitigation and Simulation perspectives:
Atomic Threat Coverage is tool which allows you to automatically generate knowledge base of analytics, designed to combat threats (based on the [MITRE ATT&CK](https://attack.mitre.org/) adversary model) from Detection, Response, Mitigation and Simulation perspectives:
- **Detection Rules** based on [Sigma](https://github.com/Neo23x0/sigma) — Generic Signature Format for SIEM Systems
- **Data Needed** to be collected to produce detection of specific Threat
@ -15,21 +17,37 @@ Atomic Threat Coverage is tool which allows you to automatically generate knowle
- **Hardening Policies** need to be implemented to mitigate specific Threat
- **Mitigation Systems** need to be deployed and configured to mitigate specific Threat
Atomic Threat Coverage provide security teams highly automatable framework for accumulation, developing, explanation and sharing actionable analytics.
Atomic Threat Coverage is highly automatable framework for accumulation, developing, explanation and sharing actionable analytics.
## Description
### Motivation
There are plenty decent projects which provide analytics (or functionality) of specific focus ([Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team), [MITRE CAR](https://car.mitre.org)). All of them have one weakness — they exist in the vacuum of their area. In reality everything is tightly connected — data for alerts doesn't come from nowhere, and generated alerts don't go nowhere. Each function, i.e. data collection, security systems administration, threat detection, incident response etc are parts of big and comprehensive process, implemented by multiple departments, which demands their close collaboration.
Sometimes problems of one function could be solved by methods of other function in a cheaper, simpler and more efficient way. Most of the tasks couldn't be solved by one function at all. Each function is based on abilities and quality of others. There is no efficient way to detect and respond to threats without proper data collection and enrichment. There is no efficient way to respond to threats without understanding of which technologies/systems/measures could be used to block specific threat. There is no reason to conduct penetration test or Red Team exercise without understanding of abilities of processes, systems and personal to combat cyber threats. All of these require tight collaboration and mutual understanding of multiple departments.
In practice there are difficulties in collaboration due to:
- Absence of common threat model/classification, common terminology and language to describe threats
- Absence common goals understanding
- Absence of simple and straightforward way to explain specific requirements
- Difference in competence level (from both depth and areas perspectives)
That's why we decided to create Atomic Threat Coverage — project which connects different functions on the same Threat Centric methodology ([Lockheed Martin Intelligence Driven Defense®](https://www.lockheedmartin.com/en-us/capabilities/cyber/intelligence-driven-defense.html) aka [MITRE Threat-based Security](https://mitre.github.io/unfetter/about/)), threat model ([MITRE ATT&CK](https://attack.mitre.org/)) and provide security teams an efficient tool for collaboration on one main challenge — combating threats.
### Why Atomic Threat Coverage
There are plenty <sup>[\[1\]](https://car.mitre.org)[\[2\]](https://eqllib.readthedocs.io/en/latest/)[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework)[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting)</sup> of analytics/detections repositories, which you have to follow, do horrible copy/pasting job, adapt information into your own internal analytics knowledge base format, detections data model, do mappings to valuable metrics and entities etc.
Work with existing <sup>[\[1\]](https://car.mitre.org)[\[2\]](https://eqllib.readthedocs.io/en/latest/)[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework)[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting)</sup> analytics/detections repositories looks like endless copy/pasting job, manual adaptation of the information into internal analytics knowledge base format, detections data model, mappings to internal valuable metrics and entities etc.
How to not create yet another analytics repository? Don't!
Atomic Threat Coverage is a tool which will allow you to create and maintain **your own** analytics repository, import analytics from other projects (or from your private forks) and do export in human-readable wiki-style pages in two possible (for now) platforms:
We decided to make it different.
1. [Atlassian Confluence](https://www.atlassian.com/software/confluence) pages ([here](https://atomicthreatcoverage.atlassian.net/wiki/spaces/DEMO/pages/10944874/win+susp+powershell+hidden+b64+cmd) is the demo of knowledge base automatically generated by Atomic Threat Coverage)
2. [This repo itself](Atomic_Threat_Coverage) — markdown formated wiki-style pages
Atomic Threat Coverage is a framework which allows you to create and maintain **your own** analytics repository, import analytics from other projects (like [Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team), as well as private forks of these projects with **your own** analytics) and do export into human-readable wiki-style pages in two (for now) platforms:
In other words, you don't have to work on data representation layer manually, you work on meaningful atomic pieces of information (like Sigma rule yaml files), and Atomic Threat Coverage will create analytics database with all entities, automatically mapped to all meaningful, actionable metrics, ready to use, ready to share and show to leadership, customers and colleagues.
1. [Atlassian Confluence](https://www.atlassian.com/software/confluence) pages ([here](https://atomicthreatcoverage.atlassian.net/wiki/spaces/DEMO/pages/10944874/win+susp+powershell+hidden+b64+cmd) is the demo of automatically generated knowledge base)
2. [This repo itself](Atomic_Threat_Coverage) — automatically generated markdown formated wiki-style pages
In other words, you don't have to work on data representation layer manually, you work on meaningful atomic pieces of information (like Sigma rules), and Atomic Threat Coverage will automatically create analytics database with all entities, mapped to all meaningful, actionable metrics, ready to use, ready to share and show to leadership, customers and colleagues.
### How it works
@ -42,10 +60,11 @@ Everything starts from Sigma rule and ends up with human-readable wiki-style pag
5. Maps Logging Policies to Data Needed using existing mapping inside Data Needed
6. Converts everything into Confluence and Markdown wiki-style pages using jinja templates (`scripts/templates`)
7. Pushes all pages to local repo and Confluence server (according to configuration provided in `scripts/config.py`)
8. Creates `analytics.csv` file for simple analytics of existing data
### Under the hood
Here is simplified description of the stuff inside:
Data in the repository:
```
├── analytics.csv
@ -57,20 +76,23 @@ Here is simplified description of the stuff inside:
│   └── dataneeded_template.yml
├── detectionrules
│   └── sigma
├── enrichments
│   ├── EN_0001_cache_sysmon_event_id_1_info.yml
│   ├── EN_0002_enrich_sysmon_event_id_1_with_parent_info.yaml
│   └── EN_0003_enrich_other_sysmon_events_with_event_id_1_data.yml
├── loggingpolicies
│   ├── LP_0001_windows_audit_process_creation.yml
│   ├── LP_0002_windows_audit_process_creation_with_commandline.yml
│   ├── LP_0003_windows_sysmon_process_creation.yml
│   ├── LP_0004_windows_audit_logon.yml
│   └── loggingpolicy_template.yml
├── triggering
│ └── atomic-red-team
└── scripts
└── triggering
└── atomic-red-team
```
#### Detection Rules
Detection Rules are unmodified [Sigma rules](https://github.com/Neo23x0/sigma/tree/master/rules), so by default Atomic Threat Coverage uses rules from official repo but you can put there rules from your own local fork.
Detection Rules are unmodified [Sigma rules](https://github.com/Neo23x0/sigma/tree/master/rules). By default Atomic Threat Coverage uses rules from official repository but you can (*should*) use rules from your own private fork with analytics relevant for you.
<details>
<summary>Detection Rule yaml (click to expand)</summary>
@ -88,7 +110,8 @@ Detection Rules are unmodified [Sigma rules](https://github.com/Neo23x0/sigma/tr
</details>
<br>
All queries automatically generated and all mappings added.
Links to Data Needed, Trigger, and articles in ATT&CK are generated automatically.
Sigma rule, Kibana query, X-Pack Watcher and GrayLog query generated and added automatically (this list could be expanded and depends on [Sigma Supported Targets](https://github.com/Neo23x0/sigma#supported-targets))
#### Data Needed
@ -103,12 +126,16 @@ All queries automatically generated and all mappings added.
</details>
<details>
<summary>Automatically created markdown (GitLab) page (click to expand)</summary>
<summary>Automatically created markdown page (click to expand)</summary>
<img src="images/dn_markdown_v1.png" />
</details>
<br>
This entity expected to explain SIEM/LM/Data Engineering teams what kind of data they could expect to receive/collect (sample). Detailed description of data type (platform/type/channel) needed for proper calculation of mappings with Detection Rules and general description. List of fields also needed for calculation of mappings and for list in analytics, so in case of triage/incident response (identification stage) analytics could easily define where they could find some specific data type (like domain name, username, hash etc).
This entity expected to simplify communication with SIEM/LM/Data Engineering teams. It includes the next data:
- Sample of the raw log to describe what data they could expect to receive/collect
- Description of data to collect (Platform/Type/Channel/etc) — needed for calculation of mappings to Detection Rules and general description
- List of fields also needed for calculation of mappings to Detection Rules and Response PLaybooks, as well as for `analytics.csv` generation
#### Logging Policies
@ -123,16 +150,16 @@ This entity expected to explain SIEM/LM/Data Engineering teams what kind of data
</details>
<details>
<summary>Automatically created markdown (GitLab) page (click to expand)</summary>
<summary>Automatically created markdown page (click to expand)</summary>
<img src="images/lp_markdown_v1.png" />
</details>
<br>
This entity expected to explain SIEM/LM/Data Engineering teams and IT departments which logging policies have to be configured to have proper Data Needed to have some specific Detection of specific Threat. It also explains how exactly this policy can be configured.
This entity expected to explain SIEM/LM/Data Engineering teams and IT departments which logging policies have to be configured to have proper Data Needed for Detection and Response to specific Threat. It also explains how exactly this policy can be configured.
#### Triggers
Triggers are unmodified [Atomic Red Team tests](https://github.com/redcanaryco/atomic-red-team/tree/master/atomics), so by default Atomic Threat Coverage uses atomics from official repo but you can put there atomics from your own local fork.
Triggers are unmodified [Atomic Red Team tests](https://github.com/redcanaryco/atomic-red-team/tree/master/atomics). By default Atomic Threat Coverage uses atomics from official repository but you can (*should*) use atomics from your own private fork with analytics relevant for you.
<details>
<summary>Triggers yaml (click to expand)</summary>
@ -145,18 +172,18 @@ Triggers are unmodified [Atomic Red Team tests](https://github.com/redcanaryco/a
</details>
<details>
<summary>Automatically created (by Atomic Red Team) markdown (GitLab) page (click to expand)</summary>
<summary>Automatically created markdown page (click to expand)</summary>
<img src="images/tg_markdown_v1.png" />
</details>
<br>
This entity needed to test specific technical controls and detections. Detailed description could be found in official [site](https://atomicredteam.io).
#### Analytics.csv
#### analytics.csv
Atomic Threat Coverage generates [analytics.csv](analytics.csv) with list of all data mapped to each other for filtering and simple analytics. This file is suppose to answer these questions:
- In which data sources I can find some specific data type (like domain name, username, hash etc), for example, during triage/incident response (identification stage)
- What data do I need to collect to detect specific threats?
- Which Logging Policies do I need to implement to collect the data I need for detection of specific threats?
- Which Logging Policies I can install everywhere (event volume low/medium) and which only on critical hosts (high/extremely high)?
@ -171,11 +198,11 @@ Ideally, this kind of mapping could provide organizations with the ability to co
## Goals
1. Stimulate community to use Sigma rule format (so we will have more contributors, more and better converters)
2. Stimulate community to use Atomic Red Team tests format (so we will have more contributors and execution frameworks)
1. Stimulate community to use [Sigma](https://github.com/Neo23x0/sigma) rule format (so we will have more contributors, more and better converters)
2. Stimulate community to use [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) tests format (so we will have more contributors and execution frameworks)
3. Evangelize threat information sharing
4. Automate most of manual work
5. Provide information security community framework which will improve communication with other departments, general analytics accumulation, developing, and sharing workflow
5. Provide information security community framework which will improve communication with other departments, general analytics accumulation, developing and sharing
## Workflow

261
README_PL.md Normal file
View File

@ -0,0 +1,261 @@
🇬🇧 [English version](README.md) | 🇷🇺 [Русская версия](README_RU.md)
# Atomic Threat Coverage
Automatycznie generowana analityczna baza wiedzy zaprojektowana, aby zwalczać zagrożenia na podstawie MITRE ATT&CK.
![](images/logo_v1.png)
<!-- ![](images/atc_description_v01.png) -->
Atomic Threat Coverage jest narzędziem, które pozwala na automatyczne generowanie analitycznej bazy wiedzy zaprojektowanej, aby zwalczać zagrożenia (na podstawie modelu "przeciwnika" przygotowanego przez [MITRE ATT&CK](https://attack.mitre.org/)) poprzez Detekcje, Reakcje, Przeciwdziałanie oraz Symulacje:
- **Detection Rules** — Reguły Wykrywania w oparciu o [Sigme](https://github.com/Neo23x0/sigma) — Generic Signature Format for SIEM Systems
- **Data Needed** — Wymagane Dane w celu odtworzenia konkretnego Zagrożenia
- **Logging Policies** — Polityki Logowania jakie muszą być skonfigurowane na urządzeniach wysyłające logi, aby móc zbierać Wymagane Dane
- **Triggers** — Wyzwalacze na podstawie [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) — testy wykrywające Zagrożenie na podstawie MITRE ATT&CK
- **Response Playbooks** — Playbooki Reakcyjne aby reagować, gdy Reguła Wyzwalania zostanie wyzwolona przez konkretne Zagrożenie
- **Hardening Policies** — Polityki Hardeningu które muszą zostać zaimplementowane, aby przeciwdziałać konkretnemu Zagrożeniu
- **Mitigation Systems** — Systemy do Przeciwdziałania które muszą zostać wdrożone, aby przeciwdziałać konkretnemu Zagrożeniu
Atomic Threat Coverage jest wysoko zautomatyzowanym frameworkiem służącym do gromadzenia, rozwijania, wyjaśniania oraz dzielenia się odpowiednią analizą.
## Opis
### Motywacja
Istnieje wiele projektów, które dostarczają analizy (lub funkcjonalność) skupiającą się na konkretnych zagadnieniach ([Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team), [MITRE CAR](https://car.mitre.org). Wszystkie z nich posiadają jedną słabość - istnieją we własnej przestrzeni. W rzeczywistości wszystko jest ściśle powiązane - dane do alertów nie biorą się znikąd, wygnerowane alerty nie idą w próżnię. Każda funkcja, jak dla przykładu zbieranie danych, administracja systemów, detekcji zagrożeń, reakcji na incydent itp są częścią kompleksowego procesu implementowanego przez wiele działów oraz wymagającego ich ścisłej współpracy.
Zdarza się, że problemy jednej funkcji mogą być w tańszy, prostszy i bardziej efektywny sposób rozwiązane przy pomocy metod stosowanych dla innej funkcji. Większość zadań nie może być rozwiązanych jedynie przy pomocy wyłącznie jednej funkcji. Każda z funkcji opiera się na możliwościach oraz jakości drugiej. Nie jest możliwa efektywna detekcja zagrożeń bez poprawnej kolekcji danych i wzbogacania ich. Nie możliwa jest także prawidłowa odpowiedź na zagrożenia bez zrozumienia, których technologii/systemów/środków można użyć do zablokowania konkretnego zagrożenia. Przeprowadzanie testów penetracyjnych lub ćwiczeń Red Team nie przynosi korzyści, jeśli nieznane są możliwości procesów, personelu i systemów do blokowania, wykrywania oraz reagowania na incydenty. Wszystko to wymaga bliskiej interakcji i zrozumienia między działami.
W praktyce problemy w kolaboracji wynikają z:
- Braku wspólnego modelu/klasyfikacji zagrożenia, wspólnej terminologii oraz języka do opisu zagrożeń
- Braku jednomyślnego pojmowania celu
- Braku prostego wyjaśnienia konkretnych wymogów
- Różnicy w kompetencjach
Dlatego zdecydowaliśmy się stworzyć Atomic Threat Coverage - projekt mający na celu połączenie różnych funkcji w ramach jednej metodologii ([Lockheed Martin Intelligence Driven Defense®](https://www.lockheedmartin.com/en-us/capabilities/cyber/intelligence-driven-defense.html) lub [MITRE Threat-based Security](https://mitre.github.io/unfetter/about/)), modelu zagrożenia ([MITRE ATT&CK](https://attack.mitre.org/)) oraz dostarczenie efektywnego narzędzia do kolaboracji nad wspólnym wyzwaniem - zwalczaniem zagrożeń.
### Dlaczego Atomic Threat Coverage
Praca z wieloma <sup>[\[1\]](https://car.mitre.org)[\[2\]](https://eqllib.readthedocs.io/en/latest/)[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework)[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting)</sup> repozytoriami analizy/detekcji często przypomina niekończącą się procedurę kopiuj/wklej, manualną adaptację informacji do formatu wewnętrzej bazy wiedzy, modeli detekcji czy mapowania na wewnętrzne metryki.
Postanowiliśmy zrobić to inaczej.
Atomic Threat Coverage jest narzędziem, które pozwala na stworzenie i utrzymywania **własnego** repozytorium analitycznego, importowanie danych z innych projektów (przykładowo [Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) jak również z prywantej kopii tych projektów z **własnymi** analizami, oraz wyeksportowanie wszystkich informacje do czytelnego dla człowieka formatu, w stylu wiki, na dwa (jak dotąd) sposoby:
1. [Atlassian Confluence](https://www.atlassian.com/software/confluence) ([tutaj](https://atomicthreatcoverage.atlassian.net/wiki/spaces/DEMO/pages/10944874/win+susp+powershell+hidden+b64+cmd) znajduje się demo bazy wiedzy automatycznie wygenerowanej przez Atomic Threat Coverage)
2. [To repozytorium samo w sobie](Atomic_Threat_Coverage) — wiki stworzona przy użyciu plików markdown
Innymi słowy, nie potrzeba już samodzielenie pracować nad warstwą prezentacji manualnie. Wystarczy skupić się na wartościowej pracy (np. tworzenie reguł Sigma), a Atomic Threat Coverage automatycznie wygeneruje analityczną bazę danych ze wszystkimi danymi, mapując wszystkie wartościowe metryki. Gotowe do użycia, udostępniania i prezentowania kierownictwu, klientowi i kolegom repozytorium.
### Zasada działania
Wszystko zaczyna się od reguł Sigma, a kończy na czytelnym dla człowieka formacie w stylu wiki. Atomic Threat Coverage parsuje regułe oraz:
1. Mapuje Regułe Wykrywania do taktyki ATT&CK używając `tags` z reguły Sigma
2. Mapuje Regułe Wykrywania do tachniki ATT&CK używając `tags` z reguły Sigma
3. Mapuje Regułe Wykrywania do Wymaganych Danych używając `logsource` i sekcji `detection` z reguły Sigma
4. Mapuje Regułe Wykrywania do Wyzwalania (testy od Atomic Read Team) używając `tags` z reguły Sigma
5. Mapuje Politykę Logowania do Wymaganych Danych używając istniejącej już mapy w Wymaganych Danych
6. Za pomocą szablonów jinja (`scripts/templates`) konwertuje wszystko w strony Confluence oraz pliki Markdown
7. Zapisuje wszystkie pliki do lokalnego repozytorium oraz na serwer Confluence (w zależności od konfiguracji w `scripts/config.py`)
8. Tworzy plik `analytics.csv` do prostej analizy istniejących danych
### Od zaplecza
Dane w repozytorium:
```
├── analytics.csv
├── dataneeded
│   ├── DN_0001_windows_process_creation_4688.yml
│   ├── DN_0002_windows_process_creation_with_commandline_4688.yml
│   ├── DN_0003_windows_sysmon_process_creation_1.yml
│   ├── DN_0004_windows_account_logon_4624.yml
│   └── dataneeded_template.yml
├── detectionrules
│   └── sigma
├── enrichments
│   ├── EN_0001_cache_sysmon_event_id_1_info.yml
│   ├── EN_0002_enrich_sysmon_event_id_1_with_parent_info.yaml
│   └── EN_0003_enrich_other_sysmon_events_with_event_id_1_data.yml
├── loggingpolicies
│   ├── LP_0001_windows_audit_process_creation.yml
│   ├── LP_0002_windows_audit_process_creation_with_commandline.yml
│   ├── LP_0003_windows_sysmon_process_creation.yml
│   ├── LP_0004_windows_audit_logon.yml
│   └── loggingpolicy_template.yml
└── triggering
└── atomic-red-team
```
#### Detection Rules
Detection Rules — Reguły Wykrywania są niezmodyfikowanymi [regułami Sigma](https://github.com/Neo23x0/sigma/tree/master/rules). Domyślnie Atomic Threat Coverage używa reguł z oficjalnego repozytorium aczkolwiek nic nie stoi na przeszkodzie, aby dołożyć reguły z własnego rezpotyrium.
<details>
<summary>Plik yaml Detection Rule (kliknij aby rozwinąć)</summary>
<img src="images/sigma_rule.png" />
</details>
<details>
<summary>Strona confluence stworzona w pełni automatycznie (kliknij aby rozwinąć)</summary>
<img src="images/dr_confluence_v1.png" />
</details>
<details>
<summary>Strona markdown (Gitlab) stworzona w pełni automatycznie (kliknij aby rozwinąć)</summary>
<img src="images/dr_markdown_v1.png" />
</details>
<br>
Linki do Wymaganych Danych, Wyzwalaczy oraz artykułów na stronie ATT&CK są generowane automatycznie.
Reguła Sigma, zapytanie dla Kibany, X-Pack Watcher oraz GrayLog są generowane oraz dodawane automatycznie (istnieje możliwość rozszerzenia generowanych zapytań na podstawie wspieranych przez projekt Sigma platform [Sigma Supported Targets](https://github.com/Neo23x0/sigma#supported-targets) )
#### Data Needed
<details>
<summary>Plik yaml Data Needed (kliknij aby rozwinąć)</summary>
<img src="images/dataneeded_v1.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona confluence (kliknij aby rozwinąć)</summary>
<img src="images/dn_confluence_v1.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona markdown (kliknij aby rozwinąć)</summary>
<img src="images/dn_markdown_v1.png" />
</details>
<br>
Ten moduł ma na celu ułatwienie komunikacji z zespołami SIEM/LM/Data Engineering. Zawiera następujęce dane:
- Przykładowy czysty log aby opisać jakich danych należy się spodziewać lub zbierać
- Opis danych do zebrania (Platform/Type/Channel/etc) - wymagany do wyznaczenia mapowania Polityk Logowania
- Listę pól wymaganą do wyznaczenia mapowania Reguł Wykrywania, Playbooki Reakcyjnych oraz wygenerowania pliku `analytics.csv`
#### Logging Policies
<details>
<summary>Plik yaml Polityki Logowania (kliknij aby rozwinąć)</summary>
<img src="images/loggingpolicy.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona confluence (kliknij aby rozwinąć)</summary>
<img src="images/lp_confluence_v1.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona markdown (kliknij aby rozwinąć)</summary>
<img src="images/lp_markdown_v1.png" />
</details>
<br>
Ten moduł ma na celu wyjaśnienie zespołom SIEM/LM/Data Engineering, lub ogólnie działom IT jakie polityki logowania muszą być skonfigurowane, aby odpowiednie dane (Wymagane Dane) były wysyłane w celu poprawnego działania Reguł Wykrywania by wykryć konkretne Zagrożenia. Dodatkowo zawarto w nim instrukcje jak krok po kroku należy takie polityki skonfigurować.
#### Wyzwalacze
Wyzwalacze to niezmodyfikowane [testy Atomic Red Team](https://github.com/redcanaryco/atomic-red-team/tree/master/atomics). Domyślnie Atomic Threat Coverage używa "atomics" z oficjalnego repozytorium, ale nic nie stoi na przeszkodzie by dodać "atomics" z własnego repozytorium.
<details>
<summary>Plik yaml Wyzwalacza (kliknij aby rozwinąć)</summary>
<img src="images/trigger.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona confluence (kliknij aby rozwinąć)</summary>
<img src="images/trigger_confluence_v1.png" />
</details>
<details>
<summary>Automatycznie wygenerowana strona markdown (kliknij aby rozwinąć)</summary>
<img src="images/tg_markdown_v1.png" />
</details>
<br>
Ten moduł pozwala na techniczne przetestowanie systemu. Szczegółowy opis można znaleźć na oficjalnej [stronie](https://atomicredteam.io).
#### Analytics.csv
Atomic Threat Coverage generuje plik [analytics.csv](analytics.csv) z listą wszystkich zmapowanych danych do filtrowania i prostej analizy. Ten plik powinien odpowiedzień na następujące pytania:
- W jakich zródłach danych można znaleźć konkrente typy danych (przykładowo nazwa domeny, nazwa użytkownika, hash etc.) podczas fazy identyfikacji?
- Jakie dane potrzebuje zbierać, aby wykryć konkretne zagrożenie?
- Które Polityki Logowania potrzebuję wdrożyć, aby zbierać dane do wykrywania konkretnego zagrożenia?
- Które Polityki Logowania mogę wdrożyć wszędzie, a które tylko na urządzeniach "krytycznych"?
- Które dane pozwalają mi na alarmy high-fidelity? (Priorytetyzacja wdrażania polityk logowania, itd.)
- itd
Takie mapowanie powinno pomóc organizacji priorytetyzować wykrywanie zagrożeń w przełożeniu na *pieniądze*, np:
- Jeśli zbieramy wszystkie Wymagane Dane ze wszystkich urządzen dla wszystkich Reguł Wykrywania, oznacza to _X_ EPS (Events Per Second) z określonymi środkami na magazynowanie danych i ich procesowanie.
- Jeśli zbieramy Wymagane Dane tylko dla alarmów high-fidelity i tylko na "krytycznych" urządzeniach, oznacza to _Y_ EPS (Events Per Second) z określonymi środkami na magazynowanie danych i ich procesowanie
- itd
## Nasze cele
1. Zachęcenie społeczności do używania formatu plików [Sigma](https://github.com/Neo23x0/sigma)
2. Zachęcenie społeczności do używania formatu testów [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team)
3. Promować dzielenie się informacją na temat zagrożeń
4. Zautomatyzować większość ręcznej pracy
5. Dostarczenie społeczności bezpieczeństwa informacji framework, który poprawi komunikacje z innymi działami, ogólną analizę, dewelopowanie i udostępnianie workflow'u
## Workflow
1. Dodaj swoje własne reguły [Sigma](https://github.com/Neo23x0/sigma) (jeśli posiadasz) do folderu `detectionrules`
2. Dodac folder z własnymi testami [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) (jeśli posiadasz) do folderu `triggering`
3. Dodaj odpowiednie Wymagane Dane związane z regułami Sigma do folderu `dataneeded` (szablon dostępny jest w `dataneeded/dataneeded_template.yml`)
4. Dodaj odpowiednie Polityki Logowania związane z Wymaganymi Danymi do folderu `loggingpolicies` (szablon dostępny jest w `loggingpolicies/loggingpolicy_template.yml`)
5. Skonfiguruj ustawienia eksportowania (markdown/confluence) - `scripts/config.py`
6. Wykonaj polecenie `make` w głównym katalogu repozytorium
## Aktualny status: Proof of Concept
Ten projekt jest aktualnie w fazie Proof of Concept i został napisany w kilka wieczorów. Nie działa dla wszystkich reguł Sigma. Przepiszemy większość skryptów, dopiszemy obsługę wszytkich oryginalnych reguł [Sigma](https://github.com/Neo23x0/sigma) oraz dodamy inne moduły (jak Playbook'i). Aktualnie chcemy pokazać dzaiałający przykład procesowania danych (reguł, itd), aby podyskutować ze społecznością, otrzymać feedback i jakiekolwiek sugestie.
## Wymagania
- Unix OS lub [Windows Subsystem for Linux (WSL)](https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux) (wymagane do wykonania polecenia `make`)
- Python 3.7.1
- Biblioteka python - [jinja2](https://pypi.org/project/Jinja2/)
- (Darmowy) Plugin do Confluence'a - [Render Markdown](https://marketplace.atlassian.com/apps/1212654/render-markdown) (open-source)
## Autorzy
- Daniil Yugoslavskiy, [@yugoslavskiy](https://github.com/yugoslavskiy)
- Jakob Weinzettl, [@mrblacyk](https://github.com/mrblacyk)
- Mateusz Wydra, [@sn0w0tter](https://github.com/sn0w0tter)
- Mikhail Aksenov, [@AverageS](https://github.com/AverageS)
## TODO
- [ ] Fix `analytics.csv` generation
- [ ] Develop Polish and Russian version of the README
- [ ] Rewrite `make` and all bash scripts in python for compatibility with Windows
- [ ] Rewrite main codebase in a proper way
- [ ] Add contribution description
- [ ] Create developer guide (how to create custom fields)
- [ ] Implement consistent Data Model (fields naming)
- [ ] Add the rest of Data Needed for default Sigma rules
- [ ] Add the rest of Logging Policies for all Data Needed
- [ ] Define new Detection Rule naming scheme (separate Events and Alerts)
- [ ] Develop docker container for the tool
- [ ] Create [MITRE ATT&CK Navigator](https://mitre.github.io/attack-navigator/enterprise/) profile generator per data type
- [ ] Create new entity called "Enrichments" which will define how to enrich specific Data Needed
- [ ] Implement new entity — "Visualisation" with Kibana visualisations/dashboards stored in yaml files and option to convert them into curl commands for uploading them into Elasticsearch
- [ ] Implement "Playbook" entity (based on Detection Rule and Data Needed) with automatic TheHive Case Templates generation (actionable Playbook)
## Linki
[\[1\]](https://car.mitre.org) MITRE Cyber Analytics Repository
[\[2\]](https://eqllib.readthedocs.io/en/latest/) Endgame EQL Analytics Library
[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework) Palantir Alerting and Detection Strategy Framework
[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting) The ThreatHunting Project
## Licencja
Dostępna w pliku [LICENSE](LICENSE).

265
README_RU.md Normal file
View File

@ -0,0 +1,265 @@
🇬🇧 [English version](README.md) | 🇵🇱 [Polska wersja](README_PL.md)
# Atomic Threat Coverage
Автоматически генерируемая база аналитических данных, предназначенная для противодействия угрозам, описанным в MITRE ATT&CK.
![](images/logo_v1.png)
<!-- ![](images/atc_description_v01.png) -->
Atomic Threat Coverage это утилита которая позволяет автоматически сгенерировать базу аналитических данных, предназначенную для противодействия угрозам, описанным в [MITRE ATT&CK](https://attack.mitre.org/) с позиций Обнаружения, Реагирования, Предотвращения и Имитации угроз:
- **Detection Rules** — правила обнаружения основанные на [Sigma](https://github.com/Neo23x0/sigma) — общем формате описания правил корреляции для SIEM систем
- **Data Needed** — данные, которые необходимо собирать для обнаружения конкретной угрозы
- **Logging Policies** — настройки логирования, которые необходимо произвести на устройстве для сбора данных, необходимых для обнаружения конкретной угрозы
- **Triggers** — сценарии имитации атак основанные на [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) — атомарных тестах/сценариях реализации угроз из MITRE ATT&CK
- **Response Playbooks** — сценарии реагирования на инциденты, сгенерированные в ходе обнаружения конкретной угрозы
- **Hardening Policies** — настройки систем, которые позволяют нивелировать конкретную угрозу
- **Mitigation Systems** — системы и технологии, которые позволяют нивелировать конкретную угрозу
Atomic Threat Coverage является автоматизированным фреймворком для сохранения, разработки, анализа и распространения практической, действенной аналитики.
## Описание
### Предпосылки
Существует много достойных проектов, которые реализуют функциональность (или предоставляют аналитику) конкретной направленности ([Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team), [MITRE CAR](https://car.mitre.org)). Их объединяет один недостаток — они существуют в вакууме свой области. В реальности же все очень тесно взаимосвязанно — данные для обнаружения угроз не берутся из ниоткуда, и генерируемые Алерты не уходят в никуда. Каждая функция, будь то сбор данных, администрирование систем защиты, обнаружение угроз или реагирование на них — это составная часть большого и сложного процесса, завязанного на несколько подразделений, требующая их плотного взаимодействия.
Проблемы одной функции зачастую проще, дешевле и эффективнее решать методами другой. Многие задачи не решаются в рамках одной функции в принципе. Каждая из функций базируется на возможностях и качеству другой. Не получится эффективно детектировать угрозы и реагировать на инциденты без сбора и обогащения необходимых данных. Не получится эффективно реагировать на инциденты без понимания того, какими средствами/системами/технологиями можоно блокировать угрозу. Крайне неэффективно проводить тестирование на проникновениве или Red Team exercises без представления о возможностях процессов, персонала и систем по блокированию, обнаружению и реагированию на инциденты. Все это требует тесного взаимодействия и взаимопонимания между подразделениями.
На практике наблюдается сложность во взаимодействии, обусловленная следующими факторами:
- Отсутствие общей модели/классификации угроз, общей терминологии
- Отсутствие понимания общих целей
- Отсутствие простого метода выражения своих потребностей
- Разница в компетенциях (как в плане глубины, так и в плане различия предметных областей)
Именно поэтому мы решили разработать Atomic Threat Coverage — проект, который призван связать разные функции под единой "Threat Centric" методологий ([Lockheed Martin Intelligence Driven Defense®](https://www.lockheedmartin.com/en-us/capabilities/cyber/intelligence-driven-defense.html) aka [MITRE Threat-based Security](https://mitre.github.io/unfetter/about/)), моделью угроз ([MITRE ATT&CK](https://attack.mitre.org/)) и предоставить подразделениям информационной безопасности эффективный инструмент для совместной работы над одной задачей — противодействию угрозам.
### Почему Atomic Threat Coverage
Работа с существующими <sup>[\[1\]](https://car.mitre.org)[\[2\]](https://eqllib.readthedocs.io/en/latest/)[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework)[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting)</sup> репозиторями аналитики выглядит как бесконечное клацание CTRL+C/CTRL+V, ручная адаптация информации под собственные нужды, модель данных, сопоставление с внутренними метриками и так далее.
Мы решили пойти иным путем.
Atomic Threat Coverage это фреймворк для создания **вашей собственной** базы знаний, импорта аналитики из других проектов (таких как [Sigma](https://github.com/Neo23x0/sigma), [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team), а также **ваших** приватных форков этих проектов с **вашей** аналитикой) и экспорта этой аналитики в удобные для восприятия человеком статьи в две (на текущий момент) платформы:
1. [Atlassian Confluence](https://www.atlassian.com/software/confluence) ([здесь](https://atomicthreatcoverage.atlassian.net/wiki/spaces/DEMO/pages/10944874/win+susp+powershell+hidden+b64+cmd) можно посмотреть автоматически сгенерированную базу знаний)
2. [В текущий репозиторий](Atomic_Threat_Coverage) — автоматически сгенерированные статьи в вики-формате на языке Markdown
Другими словами, вам не нужно работать с уровнем представления данных вручную, вы работаете только с осмысленными атомарными кусочками информации (такими как Sigma правила), и Atomic Threat Coverage автоматически создаст базу аналитики со всеми сущностями, связанными со всеми важными, действенными метриками, готовую к использованию, распространению, презентации руководству, заказчикам и коллегам.
### Как это работает
Все начинается с Sigma правила и заканчивается удобными для восприятия человеком статьями. Atomic Threat Coverage парсит Sigma правило, после чего:
1. Привязывает Detection Rule к тактике ATT&CK, используя `tags` Sigma правила
2. Привязывает Detection Rule к технике ATT&CK, используя `tags` Sigma правила
3. Привязывает Detection Rule к Data Needed, используя `logsource` и `detection` Sigma правила
4. Привязывает Detection Rule к Trigger, (Atomic Red Team тест), используя `tags` Sigma правила
5. Привязывает Logging Policies к Data Needed используя существующую в Data Needed ссылку
6. Конвертирует все в Confluence и Markdown вики-подобные статьи используя шаблоны jinja (`scripts/templates`)
7. Создает статьи в локальном репозитории и в Confluence (согласно конфигурации в `scripts/config.py`)
8. Создает `analytics.csv` файл для простой аналитики имеющихся данных
### Под капотом
Типы аналитических данных в репозитории:
```
├── analytics.csv
├── dataneeded
│   ├── DN_0001_windows_process_creation_4688.yml
│   ├── DN_0002_windows_process_creation_with_commandline_4688.yml
│   ├── DN_0003_windows_sysmon_process_creation_1.yml
│   ├── DN_0004_windows_account_logon_4624.yml
│   └── dataneeded_template.yml
├── detectionrules
│   └── sigma
├── enrichments
│   ├── EN_0001_cache_sysmon_event_id_1_info.yml
│   ├── EN_0002_enrich_sysmon_event_id_1_with_parent_info.yaml
│   └── EN_0003_enrich_other_sysmon_events_with_event_id_1_data.yml
├── loggingpolicies
│   ├── LP_0001_windows_audit_process_creation.yml
│   ├── LP_0002_windows_audit_process_creation_with_commandline.yml
│   ├── LP_0003_windows_sysmon_process_creation.yml
│   ├── LP_0004_windows_audit_logon.yml
│   └── loggingpolicy_template.yml
└── triggering
└── atomic-red-team
```
#### Detection Rules
Detection Rules — Правила Обнаружения — оригинальные, не модифицированные [Sigma правила](https://github.com/Neo23x0/sigma/tree/master/rules). По умолчанию Atomic Threat Coverage использует правила из официального репозитория, но вы можете (*вам следует*) использовать ваши собственные Sigma правила из приватного форка, с внутренней аналитикой, релевантной для вас.
<details>
<summary>Detection Rule yaml (to expand)</summary>
<img src="images/sigma_rule.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Confluence (кликните чтобы раскрыть)</summary>
<img src="images/dr_confluence.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Markdown (кликните чтобы раскрыть)</summary>
<img src="images/dr_markdown.png" />
</details>
<br>
Ссылка на Data Needed, Trigger, и статьи в ATT&CK сгенерированы автоматически.
Sigma правило, запросы для Kibana, X-Pack Watcher и запрос GrayLog сгенерированны и добавлены автоматически (этот список может быть расширен и зависит от поддерживаемых Sigma [платформах для экспорта правил](https://github.com/Neo23x0/sigma#supported-targets)).
#### Data Needed
<details>
<summary>Data Needed yaml (кликните чтобы раскрыть)</summary>
<img src="images/dataneeded.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Confluence (кликните чтобы раскрыть)</summary>
<img src="images/dn_confluence.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Markdown (кликните чтобы раскрыть)</summary>
<img src="images/dn_markdown.png" />
</details>
<br>
Эта сущность в первую очередь призвана упростить коммуникацию с SIEM/LM/Data Engineering подразделениями.
Она влючает в себя следующие данные:
- Детальное описание данных (Platform/Type/Channel/etc) необходимо для вычисления связи с Правилами Обнаружения (Detection Rules)
- Sample — пример лога, описание того как выглядят оригинальные данные, которые необходимо собирать для Обнаружения конкретных угроз и Реагирования на инциденты
- Лист доступных полей необходим для вычисления связи с Правилами Обнаружения (Detection Rules), для генерации сценариев реагирования на инциденты (Response Playbooks), а также для генерации `analytics.csv`
#### Logging Policies
<details>
<summary>Logging Policy yaml (кликните чтобы раскрыть)</summary>
<img src="images/loggingpolicy.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Confluence (кликните чтобы раскрыть)</summary>
<img src="images/lp_confluence.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Markdown (кликните чтобы раскрыть)</summary>
<img src="images/lp_markdown.png" />
</details>
<br>
Эта сущность в первую очередь призвана упростить коммуникацию с SIEM/LM/Data Engineering подразделениями.
Она влючает в себя описание конфигурации, которую необходимо реализовать на источнике данных, чтобы собирать данные (Data Needed), необходимые для Обнаружения конкретных угроз и Реагирования на инциденты.
#### Triggers
сценарии имитации атак основанные на [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) — атомарных тестах/сценариях реализации угроз из MITRE ATT&CK
Triggers — сценарии имитации атак — оригинальные, не модифицированные [Atomic Red Team тесты](https://github.com/redcanaryco/atomic-red-team/tree/master/atomics). По умолчанию Atomic Threat Coverage использует тесты из официального репозитория, но вы можете (*вам следует*) использовать ваши собственные Atomic Red Team тесты из приватного форка, с внутренней аналитикой, релевантной для вас.
<details>
<summary>Trigger yaml (кликните чтобы раскрыть)</summary>
<img src="images/trigger.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Confluence (кликните чтобы раскрыть)</summary>
<img src="images/trigger_confluence.png" />
</details>
<details>
<summary>Автоматически сгенерированная страница в Markdown (кликните чтобы раскрыть)</summary>
<img src="images/tg_markdown.png" />
</details>
<br>
Эта сущность позволяет тестировать возможности по обнаружению конкретных угроз, а также систем/механизмов/технологий обеспечения безопасности. Полное описание можно посмотреть на официальном [сайте](https://atomicredteam.io).
#### analytics.csv
Atomic Threat Coverage генерирует [analytics.csv](analytics.csv) — список данных со всеми зависимостями для простой анатилики посредством фильтров. Этот файл позволяет ответить на следующие вопросы:
- Какой источник данных может предоставить мне данные конкретного типа? (например, в ходе Реагирования на инцидент (Identification), необходимо выяснить какие источники данных могут предоставить domain name/username/hash/etc)
- Какие данные нужно собирать чтобы детектировать конкретную угрозу?
- Какие настройки логирования необходимо произвести чтобы собирать данные, необходимые для обнаружения конкретной угрозы?
- Какие настройки логирования можно произвести на всех хостах (объем данных (event volume) low/medium), а какие исключительно на критичных хостах (объем данных high/extremely high)
- Какие источники данных предоставляют возможность производить бОльшую часть Алертов с высоким уровнем критичности? (позволяет приоритизировать подключение источников)
- И так далее
В идеале, этот файл может предоставить организациям возможность выразить возможности обнаружения конкретного набора угроз **в денежном эквиваленте**. Например:
- Если мы собираем все Data Needed со всех хостов для реализации всех Detection Rules которые у нас на текущий момент есть, это будет X событий в секунду (Events Per Second, EPS) с Y ресурсов (HDD/SSD, RAM, CPU) для хранения и обработки данных (для рассчета количества данных необходимо провести ~2 недельный тест). Необходимые мощности легко выражаются в деньгах, с более-менее конкретной цифрой
- Если мы собираем Data Needed только с критичных хостов для реализации Detection Rules исключительно с высоким уровнем критичности, это будет X событий в секунду (Events Per Second, EPS) с Y ресурсов (HDD/SSD, RAM, CPU) для хранения и обработки данных (для рассчета количества данных необходимо провести ~2 недельный тест). Необходимые мощности легко выражаются в деньгах, с более-менее конкретной цифрой
- И так далее
## Цели проекта
1. Стимулировать сообщество использовать Sigma правила (больше разработчиков, больше конверторов хорошего качества)
2. Стимулировать сообщество использовать Atomic Red Team тесты (больше разработчиков, больше фреймворков исполнения хорошего качества)
3. Евангелизация распространения Cyber Threat Intelligence
4. Автоматизация ручной работы
5. Предостиавление сообщуству фреймворка для улучшения коммуникации с смежными департаментами, сохранения, разработки, анализа и распространения практической, действенной аналитики
## Алгоритм использования
1. Скопируйте ваши [Sigma](https://github.com/Neo23x0/sigma) правила (если у вас таковые есть) в директорию `detectionrules`
2. Скопируйте ваши [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) тесты (если у вас таковые есть) в директорию `triggering`
3. Создайте Data Needed в соответствии с вашими Sigma правилами в директории `dataneeded`, используя шаблон `dataneeded/dataneeded_template.yml`
4. Создайте Logging Policies в соответствии с вашими Data Needed в директории `loggingpolicies`, используя шаблон `loggingpolicies/loggingpolicy_template.yml`
5. Настройте экспорт в Confluence используя файл `scripts/config.py`
6. Исполните команду `make` в корне репозитория
## Текущая стадия разработки: Proof Of Concept
Этот проект на текущий момент находится в стадии Proof Of Concept. Он был разработан за несколько вечеров. Он не работает со всеми Sigma правилами. Мы перепишем кодовую базу, разработаем все необходимые для Sigma правил из официального репозитория Data Needed и Logging Policies, а также добавим новые сущности (Playbooks, Enrichments). На текущий момент мы хотим показать рабочий прототип для обсуждения с сообществом, получения обратной связи, комментариев и предложений по улучшению.
## Системные требования
- Unix-подобная ОС или [Windows Subsystem for Linux (WSL)](https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux) (для исполнения `make`)
- Python 3.7.1
- Библиотека [jinja2](https://pypi.org/project/Jinja2/)
- Приложение для Confluence [Render Markdown](https://marketplace.atlassian.com/apps/1212654/render-markdown) (free open source)
## Авторы
- Daniil Yugoslavskiy, [@yugoslavskiy](https://github.com/yugoslavskiy)
- Jakob Weinzettl, [@mrblacyk](https://github.com/mrblacyk)
- Mateusz Wydra, [@sn0w0tter](https://github.com/sn0w0tter)
- Mikhail Aksenov, [@AverageS](https://github.com/AverageS)
## TODO
- [ ] Исправить генерацию `analytics.csv`
- [ ] Разработать Польскую и Русскую версии README
- [ ] Переписать `make` и все bash скрипты на python для совместимости с Windows
- [ ] Переписать основную кодовую базу
- [ ] Добавить contribution guide
- [ ] Создать developer guide (как добавлять кастомные поля и сущности)
- [ ] Реализовать консистентную модель данных (наименование полей)
- [ ] Добавить оставшиеся Data Needed для правил Sigma из официального репозитория
- [ ] Добавить оставшиеся Logging Policies для всех Data Needed
- [ ] Реализовать новую схему наименования Detection Rule (разделить Events и Alerts)
- [ ] Разработать docker контейнер для утилиты
- [ ] Разработать генератор [MITRE ATT&CK Navigator](https://mitre.github.io/attack-navigator/enterprise/) профилей для каждой сущности
- [ ] Создать сущность "Enrichments", которая будет описывать процесс обогащения Data Needed
- [ ] Создать сущность "Visualisation" с визуализациями/дашбордами Kibana, сохраненными в yaml файлах и возможностью их конвертации в curl команды для загрузки в Elasticsearch
- [ ] Создать сущность "Playbook" (вычисление на базе Detection Rule и Data Needed) с автоматическим созданием TheHive Case Templates (actionable Playbook)
## Ссылки
[\[1\]](https://car.mitre.org) MITRE Cyber Analytics Repository
[\[2\]](https://eqllib.readthedocs.io/en/latest/) Endgame EQL Analytics Library
[\[3\]](https://github.com/palantir/alerting-detection-strategy-framework) Palantir Alerting and Detection Strategy Framework
[\[4\]](https://github.com/ThreatHuntingProject/ThreatHunting) The ThreatHunting Project
## Лицензия
Смотри файл [LICENSE](LICENSE).

BIN
images/logo_v1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 158 KiB