Skip to content

Latest commit

 

History

History
456 lines (288 loc) · 23.1 KB

Roota_Specification_Ukrainian.md

File metadata and controls

456 lines (288 loc) · 23.1 KB

Специфікація Roota

🌎 English

  • Версія 1.0.0
  • Дата релізу 2023-10-06

Зміст

Формат

У Roota використовується формат YAML.

Структура

name: Rule Name
details: Rule description
author: Rule author
severity: high
type: query 
class: behaviour
date: 2020-05-24
mitre-attack:
    - t1003.001
    - t1136.003
detection:
    language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
    body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
logsource:
    product: Windows                # Sigma or OCSF products
    log_name: Security              # OCSF log names
    class_name: Process Activity    # OCSF classes
    #category:                      # Sigma categories
    #service:                       # Sigma services
    audit:
        source: Windows Security Event Log 
        enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
timeline:     # for Actors and campaigns only
    2022-04-01 - 2022-08-08: Bumblebee
    2022-07-27: KNOTWEED
    2022-12-04: UAC-0082, CERT-UA#4435
references: 
    - https://badoption.eu/blog/2023/06/21/dumpit.html
tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
license: DRL 1.1
version: 1
uuid: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
#correlation: [] # extended format
#response: []    # extended format

Поля

name

Формат: текст (макс. 1024 символи)

Чи є обов'язковим: обов'язкове

Опис: Назва правила, яка показує, що і яким чином воно виявляє.

Приклад: name: Possible Credential Dumping using comsvcs.dll

details

Формат: текст (макс. 8192 символи)

Чи є обов'язковим: не обов'язкове

Опис: Короткий опис правила, який містить додатковий контекст щодо роботи алгоритму та загроз, які це правило може виявити.

Приклад: details: Adversaries can use the built-in library comsvcs.dll to dump credentials on a compromised host.

author

Формат: текст (макс. 256 символів)

Чи є обов'язковим: не обов'язкове

Опис: Ім'я того, хто створив правило. Авторам рекомендується використовувати одне й те саме ім'я для всіх своїх правил. Якщо значень декілька, вони подаються через кому.

Приклад: author: SOC Prime Team

severity

Формат: текст (макс. 16 символів)

Чи є обов'язковим: не обов'язкове

Опис: Рівень критичності правила, який показує його значимість і пріоритет розслідування у разі його спрацювання.

Можливі значення:

  • critical (критичний). Коли спрацьовують правила з рівнем критичності 'critical', необхідно терміново вжити дій. У таких правил дуже низька ймовірність хибнопозитивного спрацьовування, або ж вони пов'язані з надважливими діями, яким завжди треба приділяти першочергову увагу для запобігання негативним наслідкам.
  • high (високий). Коли спрацьовують правила з високим рівнем критичності, необхідно відкрити й провести розслідування із високим пріоритетом. Такі правила мають низьку ймовірність хибнопозитивного спрацьовування після мінімального додаткового налаштування.
  • medium (середній). Правила з середнім рівнем критичності зазвичай потребують додаткового налаштування. Якщо після налаштування таке правило спрацьовує, потрібно створювати тікет із середнім пріоритетом.
  • low (низький). Правила з низьким рівнем критичності слід використовувати в кореляціях або для цілей розслідування й отримання додаткових даних для аналізу. Деякі з таких правил можна використовувати для створення тікетів після суттєвого додаткового налаштування.

Приклад: severity: medium

type

Формат: текст (макс. 16 символів)

Чи є обов'язковим: не обов'язкове

Опис: Тип правила, який показує його призначення: query – запит для трет-хантінгу (може давати хибнопозитивні результати) або alert – правило для генерації сповіщень в реальному часі (рідко дає хибнопозитивні результати). Тип alert застосовується до правил, які в більшості середовищ матимуть низький рівень хибнопозитивних спрацьовувань або істинопозитивних спрацьовувань, що викликані нешкідливою активністю. Наприклад, якщо для правила потрібно, щоб хтось додав контроллери доменів для відфільтровування нешкідливих подій, його НЕ можна кваліфікувати як alert. Тип query застосовується до будь-якого правила, яке з високою ймовірністю доведеться додатково налаштовувати в більшості середовищ.

Можливі значення:

  • query
  • alert

Приклад: type: query

class

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Можливі значення:

  • campaign
  • behavioral
  • tool
  • generic
  • exploit
  • ioc

Опис:

  • exploit – правила для виявлення експлойтів
    Ці правила покликані виявляти експлуатацію вразливості або спробу її знайти (наприклад, CVE, загальні правила для виявлення SQL-I / XSS). Багато таких правил можна кваліфікувати як 'alert'. Як приклад, можна навести правило для детектування Log4j. Ці правила залишаються корисними необмежений час.

  • behavioral – правила для виявлення поведінки
    Ці правила призначені для виявлення патернів поведінки, що збігаються з поведінкою зловмисників, відомою по звітам про минулі інциденти. Багато таких правил можна кваліфікувати як 'query`. Прикладом правила для виявлення поведінки може бути правило, яке виявляє віддалений вхід у систему з локального акаунту адмністратора. Такі правила НЕ включають інформацію, специфічну для певної кампанії. Вони мають користь при ретроспективному застосуванні й у середньому залишаються корисними не менше 12 мсяців.

  • campaign – правила для виявлення кампаній
    Ці правила прив'язані до конкретної кампанії. Багато таких правил можна кваліфікувати як 'alert'. Як приклад можна навести правило, що виявляє кампанію за назвою сервісу, встановленого на хості Windows. Ці правила мають допомагати клієнтам визначити, чи є вони ціллю певної кампанії. Вони мають користь при ретроспективному застосуванні й у середньому залишаються корисними 3–12 місяців.

  • tool – правила для виявлення інструментів
    Ці правила виявляють використання конкретного інструмента (призначеного для кібератак або легітимного, який використовується у злочинних цілях). Як приклад можна навести правило, яке виявляє psexec. Правило, покликане виявляти psexec і будь-які подібні інструменти, де напряму не визначено характеристики, унікальні для таких інструментів, кваліфікується як правило для визначення поведінки.

  • ioc– правила для визначення індикаторів компрометації
    Правила, створені для виявлення новітніх дій зловмисників, для детектування яких не існує або майже не існує інших засобів (наприклад, wannacry, notpetya, масова експлуатація новітніми методами). Більшою частиною для індикаторів компрометації (IOC), таких як домени, IP-адреси, хеші, URL.

  • generic – загальні правила
    Ці правила призначені для виявлення потенційних слабких місць у середовищі. Як приклад можна навести правило, яке виявляє слабке шифрування в Kerberos (RC4_HMAC_MD5). Ці правила дозволяють отримати інформацію, яка з дуже низькою ймовірністю буде істинопозитивним результатом, але клієнтам корисно її знати. Наприклад, використання акаунта root-юзера в AWS.

Приклад: class: campaign

date

Format: YYYY-MM-DD

Чи є обов'язковим: не обов'язкове

Опис: Дата створення правила.

Приклад: date: 2022-10-31

mitre-attack

Формат: текст (макс. 1024 символи)

Чи є обов'язковим: не обов'язкове

Опис: перелік ідентифікаторів технік, підтехнік, груп та програмного забезпечення за системою MITRE ATT&CK(r). Усі ідентифікатори мають бути в нижньому регістрі.

Приклад:

mitre-attack:
    - t1136.003
    - t1087.004
    - t1069

detection

Чи є обов'язковим: обов'язкове

Опис: Ця секція містить поля, в яких задано логіку детектування і мову, якою вона написана. Див. специфікацію цих полів нижче.

language

Формат: текст (макс. 128 символів)

Чи є обов'язковим: обов'язкове

Опис: Це поле містить назву SIEM/EDR/XDR у відповідному форматі. Див. перелік підтримуваних платформ у розділі "Можливі значення".

Можливі значення:

  • sentinel-kql-query для Microsoft Sentinel Query
  • splunk-spl-query для Splunk Query
  • crowdstrike-spl-query для CrowdStrike Query
  • elastic-lucene-query для Elasticsearch Query
  • opensearch-lucene-query для AWS OpenSearch Query
  • logscale-lql-query для Falcon LogScale Query
  • mde-kql-query для Microsoft Defender for Endpoint Query
  • qradar-aql-query для IBM QRadar Query
  • athena-sql-query для AWS Athena Query (Security Lake)
  • chronicle-yaral-query для Chronicle Security Query
  • fortisiem-rule for FortiSIEM Rule
  • axon-ads-rule for LogRhythm Axon Rule
  • axon-ads-query for LogRhythm Axon Query

Приклад: language: splunk-spl-query

body

Формат: текст (макс. 8192 символи)

Чи є обов'язковим: обов'язкове

Опис: Ця секція містить логику правила. Це має бути запит у нативному форматі певної системи SIEM/EDR/XDR. Запит має складатися з одного рядка. Якщо запит складається з декількох рядків, об'єднайте їх, перш ніж додавати в правило Roota.

Приклад: index=* source="WinEventLog:*" AND (Image="*.exe" OR Image="*.com")

logsource

Чи є обов'язковим: не обов'язкове

Опис: Ця секція описує джерела логів, потрібні для роботи правила. Вона не обов'язкова, але може бути необхідною у випадках, коли логіка детектування не описує потрібні джерела логів.

product

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Продукт, від якого надійшли дані про подію.

Приклад: product: windows

log_name

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Назва логу події. Наприклад, назва файлу syslog або підсистеми логування Windows: Security.

Приклад: log_name: Security

class_name

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Класи подій за OCSF. Детальний опис можна знайти тут: https://schema.ocsf.io/1.0.0/classes

Приклад: class_name: Process Activity

category

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Категорія використовується, коли різні джерела даних забезпечують той самий тип логування подій. Наприклад, Microsoft Windows 4688 та Sysmon Event ID 1 обидва логують створення процесів і мають багато спільних полів. Тож, можна створювати й використовувати правила, написані під загальну категорію "process_creation", а не конкретне джерело даних. Це також стосується більшості фаєрволів, проксі, тощо.

Приклад: category: process_creation

service

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Сервіс використовується, коли для необхідних логів подій існує конкретне джерело даних. Наприклад, події Amazon Cloudtrail логуються лише в AWS. Зазвичай правило, написане під певний сервіс, не можна використати з іншим джерелом даних.

Приклад: service: apache

audit

Чи є обов'язковим: не обов'язкове

Опис: Ця секція містить докладний опис того, які сервіси логування необхідно ввімкнути, щоб мати логи, необхідні для даного правила.

source

Формат: текст (макс. 128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Повна назва постачальника логів або сервісу логування, які записують подію. Наприклад, Microsoft-Windows-Security-Auditing.

Приклад: source: Microsoft-Windows-PowerShell/Operational

enable

Формат: текст (макс. 2048 символів)

Чи є обов'язковим: не обов'язкове

Опис: Ця секція містить докладні вказівки, як увімкнути запис необхідних логів аудиту в системі-джерелі.

Приклад: enable: 'Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process Creation'

timeline

Формат:

YYYY-MM-DD - YYYY-MM-DD: Актор1, Актор2, TLP:CLEAR
YYYY-MM-DD: Актор1, Актор3, TLP:GREEN

Чи є обов'язковим: не обов'язкове

Опис: Має включати ім'я актора, маркування за протоколом TLP і дати, коли актор проявляв поведінку, описану в правилі Roota. На відміну від індикаторів компрометації, які є специфічними для актора, одні й ті самі патерни поведінки можуть застосовуватися різними акторами. Якщо маркування за протоколом TLP не задано, то вважається, що воно має значення TLP:CLEAR. Період може задаватися двома датами (перше й останнє проявлення) або однією датою.

Приклад:

timeline:
    2023-01-01 - 2023-03-06: Ducktail, MerlinAgent
    2023-02-04: Lazarus

references

Формат: текст (макс. 2048 символів)

Чи є обов'язковим: не обов'язкове

Опис: Посилання на статті у ЗМІ, публікації або інші джерела, які описують загрозу, експлойт, поведінку, тощо, які виявляє правило.

Приклад:

references: 
    - https://badoption.eu/blog/2023/06/21/dumpit.html

tags

Формат: текст (макс. 1024 символи)

Чи є обов'язковим: не обов'язкове

Опис: Короткі слова, подані через кому, які позначають правило Roota для пошуку за ключовими словами.

Приклад: tags: MerlinAgent, UAC-0173, UAC-0006, Ducktail, CERT-UA#4753

license

Формат: текст (макс. 256 символів)

Чи є обов'язковим: не обов'язкове

Опис: Ліцензія правила. Також може містити посилання на файл з ліцензією.

Приклад: license: DRL 1.1

version

Формат: X.X (суттєвий.несуттєвий номер версії)

Чи є обов'язковим: не обов'язкове

Опис: Унікальний номер версії правила.

Приклад: version: 0.1

uuid

Формат: текст (32 символи)

Чи є обов'язковим: не обов'язкове

Опис: Унікальний ідентифікатор правила. Рекомендується використовувати UUID версії 4.

Приклад: uuid: 009a001b-1623-4320-8369-95bf0d651e8e

correlation

Чи є обов'язковим: не обов'язкове

Опис: У цій секції виконується кореляція результатів запиту.

Приклад:

correlation: 
    timeframe: 1m
    functions: count() > 10

timeframe

Формат: текст (8 символів)

Чи є обов'язковим: не обов'язкове

Опис: Період часу для функцій, який задається у секундах (s), хвилинах (m), годинах (h), днях (d) або тижнях (w).

Приклад: timeframe: 1m

functions

Формат: текст (128 символів)

Чи є обов'язковим: не обов'язкове

Опис: Функції можна використовувати для кореляції результатів запиту, наприклад, щоб правило спрацьовувало, лише якщо досягаються певні граничні значення певних полів. Це поле все ще в розробці. Першими будуть реалізовані такі функції:

  • count() – кількість значень поля
  • by – групування по полю
  • dcount – унікальні значення поля

Приклад: functions: count() > 10

response

Зарезервовано на майбутнє.