Přeskočit obsah

Deklarace pro definování základních linií

Deklarace pro základní linie jsou načítány z Knihovny ze složky určené v konfiguraci, například /Baseliners.

Poznámka

Baseliner ve výchozím nastavení používá /Schemas/ECS.yaml, takže /Schemas/ECS.yaml musí být také přítomen v Knihovně.

Prohlášení

Toto je příklad základní definice, umístěné ve složce /Baseliners v Knihovně:

---
define:
    name: Dataset
    description: Creates baseline for each dataset and trigger alarms if the actual number deviates
    type: baseliner

baseline:
    region: Czech Republic
    period: day
    learning: 4
    classes: [workdays, weekends, holidays]
    max_history_days: 180  # (optional) Maximum days of counter history to retain
    model: negbin

evaluate:
    key: event.dataset
    timestamp: "@timestamp"

analyze:
    when: 1h  # How often to perform the analysis (1 hour is the default)
    test:
        !AND
        - !LT
            - !ARG VALUE
            - 1
        - !GT
            - !ARG MEDIAN
            - 0
        - !GT
            - !ARG SIGMA
            - 5.0

trigger:
    - event:
            # Threat description
            # https://www.elastic.co/guide/en/ecs/master/ecs-threat.html
            threat.framework: "MITRE ATT&CK"
            threat.indicator.sightings: !ITEM EVENT value
            threat.indicator.confidence: "High"
            threat.indicator.name: !ITEM EVENT dimension

    - notification:
            type: email
            to: ["myemail@example.co"]
            template: "/Templates/Email/Notification_baseliner_dimension.md"

            variables:
                name: "Logs are not coming to the dataset within the given UTC hour."
                dimension: !ITEM EVENT dimension
                hour: !ITEM EVENT hour

Sections

základní úroveň

baseline: # (1)
    region: Czech Republic #(2)
    period: day # (3)
    learning: 4  # (4)
    classes: [workdays, weekends, holidays] # (5)
    max_history_days: 180  # (6)
    model: normal  # (7)
  1. Defines how the given baseline is built.
  2. Defines in which region the activity is happening (for calculating holidays and so on).
  3. Defines the timespan for the baseline. The period can be either day or week.
  4. Defines the number of periods (here day) that occur from the baseliner beginning to receive input until the user can see the baseline analysis. Additional details below.
  5. Define which days in the week we want to monitor. Classes can include any/all: workdays, weekends, and holidays.
  6. max_history_days (optional): Maximum number of days of counter history to retain for baseline building. Counter records older than this limit are automatically deleted to prevent memory leaks and excessive storage usage. If not specified, defaults to the configuration value max_baseline_history_days (default: 60 days if not configured). This parameter helps manage long-term data retention while ensuring sufficient history for accurate baseline calculations. Optional max_history_days_per_class overrides the window per temporal class (see below).
  7. model (optional): Statistical model used when scoring the current hour against the learned mean and variance. One of normal (default), poisson, or negbin (Negative Binomial with automatic Poisson fallback). See Statistical model.

learning
Pole learning definuje fázi učení.
Fáze učení je čas od prvního výskytu hodnoty dimenze ve vstupu instance Baseliner až do okamžiku, kdy je uživateli zobrazena základní linie a proběhne analýza. V deklaraci je learning počet období. Fáze učení se počítá zvlášť pro svátky, víkendy a pracovní dny. Základní linie jsou obnovovány přes noc (údržba).

V tomto příkladu je period den, takže learning je 4 dny. S ohledem na kalendář znamená fáze učení trvající 4 dny začínající v pátek 4 pracovní dny, a tedy končí ve středu večer.

max_history_days Pole max_history_days určuje maximální počet dní historie čítače, které se mají uchovávat pro tvorbu základní linie. Tento parametr pomáhá předcházet únikům paměti a nadměrnému využívání úložiště tím, že automaticky maže záznamy čítače starší než je stanovený limit.

  • Výchozí chování: Pokud není uvedeno v deklaraci základní linie, systém používá konfigurační hodnotu max_baseline_history_days z konfigurace baselineru (výchozí: 60 dní, pokud není nakonfigurováno).
  • Automatické čištění: Během sestavování základní linie (obvykle přes noc) jsou záznamy čítače starší než max_history_days automaticky odstraněny z MongoDB.
  • Dopad na základní linii: Pro výpočty základní linie se používají pouze záznamy čítače v rámci okna max_history_days. Starší data jsou vyloučena, aby byla základní linie relevantní vůči nedávným vzorcům aktivit.
  • Doporučení: Nastavte tuto hodnotu podle požadavků na základní linii. Například:
  • 60–90 dní: Vhodné pro většinu případů použití, poskytuje dobrý poměr mezi historií a výkonem
  • 180 dní (6 měsíců): Pro základní linie vyžadující dlouhodobé vzorce, například sezónní změny
  • 30 dní: Pro prostředí s vysokým objemem, kde je omezená kapacita úložiště

Správa úložiště

Parametr max_history_days je obzvláště důležitý pro baseliny s vysokým objemem nebo pro dlouhodobě běžící systémy. Bez tohoto omezení se mohou záznamy počítadla hromadit neomezeně, což vede ke zvýšenému využití úložiště a pomalejším výpočtům baselinu.

max_history_days_per_class (volitelné)
Přepište okno historie pro jednotlivé časové třídy. workdays a weekends mají výchozí hodnotu max_history_days. holidays má výchozí hodnotu 400 dní (~13 měsíců), takže celý rok státních svátků se vejde, pokud je globální okno 60 dní. Uchovávání počítadel používá nejdelší nastavené okno.

baseline:
    max_history_days: 60
    # optional override; holidays already default to 400:
    # max_history_days_per_class:
    #   holidays: 400

merge_holidays_into_weekends (volitelné, výchozí false)
Pokud je nastaveno na true, státní svátky v kalendáři jsou klasifikovány jako víkendy pro tvorbu a analýzu základního mixu. Použijte toto nastavení, pokud jsou svátky příliš vzácné na samostatnou třídu v okně historie (běžné u max_history_days: 60). Preferujte kombinaci classes: [workdays, weekends] spolu s tímto přepínačem.

baseline:
    classes: [workdays, weekends]
    merge_holidays_into_weekends: true

Statistický model

baseline.model vybírá jeden pravděpodobnostní model pro analýzu aktuální hodiny. Vypočítávají se pouze skóre toho modelu.

Výběr modelu
Model Doporučené použití Vhodné příklady
normal (default) Přibližně symetrické spojené hodnoty, zejména podepsaná měření, nekoncentrovaná poblíž tvrdé hranice Chyba měření nebo reziduum, posun hodin, odchylka teploty od nastaveného bodu, odchylka frekvence nebo napětí od nominální hodnoty
poisson Počty událostí s relativně stabilní odchylkou kolem jejich průměru Pravidelná plánovaná činnost, stabilní počet transakcí, periodické stavové události
negbin Počet událostí, které jsou nárazové nebo více proměnlivé než Poisson, mohou reprezentovat Objemy záznamů, autentizační události, síťové události

Pokyny: použijte normal pro přibližně symetrická spojitá měření. Použijte poisson nebo negbin pro počet událostí. Pokud modelujete hrubé počty událostí a nejste si jisti, zda je vhodný Poisson, použijte negbin: je to Negative Binomial model počtů s automatickým přepnutím na Poisson pro profily, které nevykazují dostatečnou overdisperzi.

Nepoužívejte normal pro surové počty událostí. Normální model může někdy přiblížit ohraničená nebo zkosená data mimo hranici, ale počty blízko nule jsou lépe řešeny pomocí poisson nebo negbin.

baseline:
    region: Czech Republic
    period: week
    learning: 2
    classes: [workdays, weekends, holidays]
    model: negbin
Pochopení výstupů analýzy

Konfigurace (baseline.*) určuje, jak je baseline vytvořena a který model hodnotí aktuální hodinu. Níže uvedené atributy jsou vypočítané hodnoty dostupné v analyze.test.

Atribut Laskavý Význam
VALUE Pozorování Aktuální aktivita pro toto analytické okno (počet událostí nebo norma vektoru při aggregation: vector)
MEAN, STDEV, VARIANCE, MEDIAN, MIN, MAX, SUM Naučená historie Souhrnné statistiky srovnatelných minulých hodin pro stejnou třídu
SIGMA Skóre modelu Velikost anomálie na běžné normálně-ekvivalentní škále vzácnosti (viz níže)
DIRECTION Skóre modelu Zda je pozorování nezvykle nízké, vysoké nebo ani jedno (viz níže)
LOG_P0 Skóre modelu Přirozený logaritmus P(X ≤ 0) podle nastaveného modelu (viz níže)
MODEL Kontext Nakonfigurovaný název modelu (normal, poisson nebo negbin)
HOUR, KEY, CLASS, TENANT Kontext Slot, který je analyzován

SIGMA

SIGMA vyjadřuje, jak vzácný je pozorovaný jev podle nakonfigurovaného modelu, na běžné škále ekvivalentní normálnímu rozdělení. Větší hodnota znamená vzácnější pozorování.

  • S model: normal se jedná o konvenční absolutní z-skóre |VALUE − MEAN| / STDEV.
  • S model: poisson nebo model: negbin je pravděpodobnost pozorovaného počtu převedena na ekvivalentní jednostranné normální z-skóre.

To umožňuje zachovat použitelnost existujících prahů SIGMA napříč modely, i když se liší základní pravděpodobnostní model.

Jednostranná pravděpodobnost ocasu popisuje pozorování, která jsou alespoň stejně extrémní v jednom určeném směru. U pravidla nezávislého na směru je pravděpodobnost dosažení stejné vzácnosti v jakémkoli ocasu přibližně dvojnásobkem jednostranné pravděpodobnosti:

SIGMA Jednostranná pravděpodobnost ocasu Pravděpodobnost obou ocásků Přibližná frekvence s hodinovým vyhodnocením
3 1.35×10⁻³ 2.70×10⁻³ jednou za 370 hodin (~dvakrát za měsíc)
4 3.17×10⁻⁵ 6.33×10⁻⁵ jednou za 15 800 hodin (~jednou za 1,8 roku)
5 2.87×10⁻⁷ 5.73×10⁻⁷ jednou za 1,74 milionu hodin (~jednou za 199 let)

Například SIGMA = 3 znamená jednostrannou pravděpodobnost v ocasu přibližně 0.00135. Hodnota alespoň takto neobvyklá v kterémkoli směru má pravděpodobnost přibližně 0.0027, což je zhruba jeden výskyt na 370 hodnocení. Při hodinovém hodnocení to je v průměru asi dvakrát za měsíc.

Jedná se o pravděpodobnostní ekvivalence, nikoli o předpovědi běžného rozvrhu. Interpretace frekvence předpokládá, že model je dobře kalibrován a že porovnatelné evaluační intervaly jsou dostatečně nezávislé. Směrové pravidlo, jako například DIRECTION: LOW, používá jednostrannou pravděpodobnost; pravidlo, které se zaměřuje na stejně extrémní hodnoty v obou směrech, používá oboustrannou pravděpodobnost.

Začněte s prahovými hodnotami kolem 5, když jsou falešně pozitivní výsledky nákladné; použijte 4, pokud je důležitější dřívější detekce. Prahovou hodnotu zvyšte, pokud jsou upozornění příliš hlučná.

SMĚR

  • LOW — pozorovaná hodnota je neobvykle nízká
  • HIGH — pozorovaná hodnota je neobvykle vysoká
  • NEUTRAL — pozorování není jasně spojeno s žádnou stranou rozdělení

SIGMA popisuje velikost anomálie; DIRECTION popisuje, zda je na nízké nebo vysoké straně základní hodnoty. To usnadňuje psaní pravidel, která rozlišují ticho od náhlých nárůstů provozu.

MODEL

MODEL uvádí konfigurovaný statistický model. Při model: negbin může individuální základní profil interně použít Poissonovu náhradu, když není přítomna nadměrná disperze.

LOG_P0

LOG_P0 = ln(P0) kde P0 = P(X ≤ 0) podle nakonfigurovaného modelu.

  • U modelů počtu událostí (poisson, negbin) je to pravděpodobnost pozorování nulového počtu událostí.
  • U normal je to pravděpodobnost, že hodnota spadne na nebo pod nulovou hranici (pro spojitá data platí P(X ≤ 0) stejně jako P(X < 0)).

Více záporných hodnot znamená, že dosažení nuly je při normálním provozu méně pravděpodobné. U většiny detekčních pravidel upřednostněte SIGMA; použijte LOG_P0, když potřebujete přesný pravděpodobnostní práh nebo bayesovskou posteriéri pravděpodobnosti výpadku.

LOG_P0 P0 Rovnocenné SIGMA při nule
−6.61 ≈ 1.35×10⁻³ 3
−10.36 ≈ 3.17×10⁻⁵ 4
−15.06 ≈ 2.87×10⁻⁷ 5

Pro vektorové základní linie a kódy událostí na hostitelích Windows viz Detekce anomálií uživatelské aktivity.

Detekce ticha nebo výpadku

Hlavní vzorec používá VALUE, MEDIAN a SIGMA: 

baseline:
    model: negbin

analyze:
    test:
        !AND
        - !LT
            - !ARG VALUE
            - 1
        - !GT
            - !ARG MEDIAN
            - 0
        - !GT
            - !ARG SIGMA
            - 5.0

Toto se spustí, když je aktuální hodina tichá, srovnatelné historické hodiny obvykle nejsou prázdné (MEDIAN > 0) a ticho je výjimečně neobvyklé podle konfigurovaného modelu počtu. SIGMA = 5 je konzervativní výchozí příklad; snižte ji (například na 4), pokud je důležitější dřívější detekce, nebo ji zvyšte, pokud je příliš mnoho falešně pozitivních výsledků. Použijte výše uvedenou tabulku vzácnosti k interpretaci přibližné hodinové frekvence této volby.

Profily s MEDIAN == 0 (historicky často tiché) by obvykle neměly automaticky upozorňovat; výše uvedená ochrana MEDIAN to řeší.

Pokročilé: pravidla výpadků založená na pravděpodobnosti

Baseliner nevypočítává Bayesovský posterior výpadku. LOG_P0 popisuje, jak překvapivý je ticho během zdravého provozu. Posterior také závisí na tom, jak běžné jsou výpadky a jak spolehlivě výpadek způsobí úplné ticho.

Nechť:

  • O — sledovaný zdroj je v režimu výpadku
  • H — funguje normálně
  • q = P(O) — apriorní pravděpodobnost, že srovnatelné hodnotící okno je ovlivněno výpadkem
  • r = P(X=0 | O) — pravděpodobnost pozorování žádných událostí během výpadku
  • p0 = P(X=0 | H) — pravděpodobnost nulového počtu událostí podle nakonfigurovaného modelu zdravého stavu (exp(LOG_P0) pro modely počtu)

Po pozorování nulových událostí:

P(O | X=0) = (q · r) / (q · r + (1 − q) · p0)

Předchozí q by mělo představovat výskyt výpadků na srovnatelné časové okno analýzy, nikoli libovolné nastavení důvěry. Pro úplný výpadek zdroje může být r = 1 rozumné; pro částečné nebo přerušované výpadky je realističtější r < 1.

Pro požadovaný posteriorní práh a se podmínka převádí na práh pro pravděpodobnost nulového stavu zdraví:

P(O | X=0) ≥ a  ⇔  p0 ≤ (q · r · (1 − a)) / (a · (1 − q))

LOG_P0 ≤ ln( (q · r · (1 − a)) / (a · (1 − q)) )

Příklad. Předpokládejme q = 0,001, úplné ticho během výpadku (r = 1) a požadovaný posterior a = 0,95. Pak p0 ≤ 5,2684×10⁻⁵ a LOG_P0 ≤ −9,8512. Při VALUE = 0 je to přibližně SIGMA ≥ 3,878. Praktické pravidlo může použít více přístupné rozhraní SIGMA:

analyze:
    test:
        !AND
        - !EQ
            - !ARG VALUE
            - 0
        - !GE
            - !ARG SIGMA
            - 3.878

Prahová hodnota platí pouze pro uvedené předpoklady. Pokud se q nebo r změní, přepočítejte ji. Při nulové hodnotě jsou SIGMA, LOG_P0 a posteriorní pravděpodobnost monotónní transformace stejného důkazu modelu pro pevné q a r — nejde o tři nezávislé signály.

zdroj protokolu (volitelné)

Sekce logsource určuje typy událostních kanálů, ze kterých by měly být příchozí události čteny. Používá se k třídění zdroje záznamů a je odvozen z Sigma pravidel.

logsource:
  vendor:
    - microsoft
  product:
    - windows

Sekce logsource může obsahovat:

  • vendor: Dodavatel zdroje protokolu (např. microsoft, linux, cisco)
  • product: Název produktu (např. windows, exchange, fortigate)
  • service (volitelné): Název služby (např. syslog, audit, activitylogs)

Každé pole přijímá seznam hodnot. Události z událostních pruhů, které odpovídají některé ze specifikovaných hodnot dodavatele, produktu nebo služby, budou zohledněny pro základní linii.

!!! příklad "Příklad: Základní nastavení událostí Windows"yaml logsource: vendor: - microsoft product: - windows

This configuration will process events from event lanes that are categorized as Microsoft Windows logs.

!!! příklad "Příklad: Více produktů"yaml logsource: vendor: - microsoft product: - windows - exchange - office365

This configuration will process events from Microsoft Windows, Exchange, or Office 365 event lanes.

signál (volitelný)

Volitelná sekce signal kontroluje, zda základní linie (baseline) odesílá signál do Správy upozornění a jak jsou tikety seskupovány. Použijte signal: default: false, když je základní linie určena pouze pro analýzu nebo jako vstup pro korelaci (bez přímého vytváření tiketů). Použijte signal: grouping:, abyste nastavili, které atributy se používají pro seskupování tiketů. Podrobnosti naleznete v Signal.

predikát (volitelný)

Sekce predicate filtruje příchozí události, aby byly považovány za aktivitu v základní úrovni.

Pište filtry pomocí TeskaLabs SP-Lang. Podrobnosti najdete v sekci Predikáty nebo v dokumentaci SP-Lang.

Kombinace logsource a predicate

Sekce logsource filtruje události na úrovni řetězce událostí (které řetězce událostí číst), zatímco sekce predicate filtruje jednotlivé události v těchto řetězcích. Oba filtry se aplikují, takže událost musí splňovat jak kritéria logsource, tak výraz predicate, aby byla zahrnuta do základní linie.

hodnotit

Tato sekce specifikuje, které atributy z události budou použity ve výchozí sestavě.

evaluate:
    key: event.dataset # (1)
    timestamp: "@timestamp" # (2)
  1. Určuje atribut/entity, kterou je třeba sledovat.
  2. Určuje atribut, ve kterém je uložen časový rozměr aktivity události.

key_aliases (volitelné, od verze v25.47.02)

V sekci evaluate můžete přidat key_aliases pro mapování hodnot dimenzí na jediný klíč. To normalizuje různé hodnoty událostí, takže jsou počítány pod jedním klíčem dimenze.

evaluate:
    key: myuser
    key_aliases:
        myuser1: myuser
        myuser2: myuser
        myuser3: myuser
    timestamp: "@timestamp"
  • Událost s myuser: "myuser1" je započítána pod klíčem myuser.
  • Událost s myuser: "myuser2" je také započítána pod klíčem myuser.
  • Hodnoty, které nejsou uvedeny v key_aliases, zůstávají nezměněny (např. myuser4 zůstává myuser4).

Přezdívky se aplikují na všechny typy hodnot dimenzí (řetězec, celé číslo, seznam po spojení, IP po převodu): hodnota je převedena na řetězec a poté se aplikuje mapování key_aliases.

analyzovat

Sekce test v analyze určuje, kdy spustit spouštěč, pokud se skutečná aktivita (!ARG VALUE) odchýlí od základní hodnoty. Testy pište v SP-Lang.

Během analýzy Baseliner porovnává aktuální aktivitu pro daný rozměr (klíč), hodinu a časovou třídu (pracovní dny, víkendy, svátky) se získanými statistikami pro stejný časový úsek.

Ve výchozím nastavení (analyze.when: 1h) watcher běží přibližně jednou za hodinu a hodnotí předchozí dokončenou UTC hodinu vůči čítačům uloženým v té době. Spouštěče se aktivují pouze, pokud analyze.test pro tento snímek projde. Tato hodina není později znovu analyzována.

Vypočtené skóre (SIGMA, DIRECTION, LOG_P0, MODEL) a výběr modelu jsou popsány v sekci Statistical model. Vzor ticha / výpadku s využitím VALUE, MEDIAN a SIGMA je doporučeným výchozím bodem pro počítané základy.

Pozdní události vs. uživatelské rozhraní analýzy

API pro základní hodnoty (a analýza grafu v uživatelském rozhraní) přepočítává SIGMA pro historické hodiny z čítačů, které existují nyní. To se může lišit od toho, co pozorovatel viděl, když byla hodina uzavřena.

Příklad. Základní nastavení hostitele používá model: negbin a !GT !ARG SIGMA 5. Krátce po 11:00 UTC analyzuje watcher období 10:00–11:00. Pokud jsou události za tuto hodinu v pipeline stále zpožděné, je čítač stále 0, takže SIGMA zůstává nízká a nevytvoří se žádná složitá událost ani signál. Později stejná hodina ukazuje v UI actual: 95 a SIGMA: 100 — čítače dorazily po analýze. Watcher se pro tuto hodinu již nespustí znovu, takže se zpětně žádné upozornění nevytvoří.

Při vyšetřování chybějícího upozornění porovnejte záznamy sledovače za tu hodinu s tím, zda čítače již existovaly v době analýzy; vysoké SIGMA v grafu samotném neznamená, že spouštěč běžel.

Příklad: absolutní prahy

analyze:
    test:
        !AND #(1)
        - !LT #(2)
            - !ARG VALUE # (3)
            - 1
        - !GT # (4)
            - !ARG MEAN # (5)
            - 10.0
  1. Všechny výrazy zanořené pod AND musí být pravdivé, aby test prošel. Zde, pokud je hodnota menší než 1 a průměr je větší než 10, spustí se spouštěč.
  2. „Menší než“
  3. Získej (!ARG) hodnotu (VALUE). Pokud je hodnota menší než 1, jak je specifikováno, výraz !LT je pravdivý.
  4. „Větší než“
  5. Získej (!ARG) průměr (MEAN). Pokud je průměr větší než 10.0, jak je specifikováno, výraz !GT je pravdivý.

Příklad: práh sigma (špička nebo ticho)

baseline:
    model: negbin  # or normal / poisson

analyze:
    when: 1h
    test:
        !GT
        - !ARG SIGMA
        - 5

Kombinujte s DIRECTION, když vás zajímá pouze jedna strana (například hroty):

analyze:
    test:
        !AND
        - !EQ
            - !ARG DIRECTION
            - HIGH
        - !GT
            - !ARG SIGMA
            - 5

Ticho / příklad stažení datového souboru (stejně jako v Detekce ticha nebo výpadku):

baseline:
    model: negbin

analyze:
    test:
        !AND
        - !LT
            - !ARG VALUE
            - 1
        - !GT
            - !ARG MEDIAN
            - 0
        - !GT
            - !ARG SIGMA
            - 5.0

Dostupné atributy !ARG

Následující atributy jsou dostupné v notaci SP-Lang uvnitř analyze.test:

TENANT: "str",
VALUE: "ui64",
STDEV: "fp64",
MEAN: "fp64",
SIGMA: "fp64",
DIRECTION: "str",
LOG_P0: "fp64",
MODEL: "str",
MEDIAN: "fp64",
VARIANCE: "fp64",
MIN: "ui64",
MAX: "ui64",
SUM: "ui64",
HOUR: "ui64",
KEY: "str",
CLASS: "str",

Možnost when určuje, jak často provádět analýzu.

spoušť

Sekce trigger definuje aktivitu, která se spustí po úspěšné analýze. (Více o triggerech.)

Baseliner vytváří události

Při každé analýze (každou hodinu) Baseliner vytvoří událost, která shrnuje jeho analýzu. Tyto události vytvořené Baselinerem jsou k dispozici k použití (jako EVENT) s výrazy jako !ARG a !ITEM, což znamená, že z událostí můžete získávat hodnoty pro své spouštěcí aktivity.

Tyto události vytvořené Baselinerem zahrnují pole:

nájemce Jméno nájemce, ke kterému základní úroveň patří.

rozměr Rozměr, ke kterému základní linie patří, jak je určeno v evaluate.

třída Třída, ze které byla vypočítána základní hodnota. Možnosti zahrnují: pracovní dny, víkendy a svátky

hodina Počet UTC hodiny, ve které analýza proběhla.

hodnota Hodnota aktuálního čítače událostí pro danou hodinu UTC.

Analytické skóre pro stejnou událost (použitelné přes !ITEM EVENT …) zahrnuje mean, stdev, sigma, direction, log_p0 a model.

Spouštěč oznámení

Spouštěč oznámení odesílá zprávu, například e-mail. Podrobnější informace o odesílání e-mailových oznámení a používání e-mailových šablon naleznete v části E-mailová oznámení.

Příklad spouštěče oznámení:

trigger:
    - notification:
            type: email #(1)
            to: ["myemail@example.co"] # (2)
            template: "/Templates/Email/Notification_baseliner_dimension.md" # (3)

            variables: # (4)
                name: "Logs are not coming to the dataset within the given UTC hour."
                dimension: !ITEM EVENT dimension # (5)
                hour: !ITEM EVENT hour
  1. Určuje emailové upozornění
  2. Adresa příjemce
  3. Cesta k souboru šablony emailu v knihovně LogMan.io
  4. Začíná sekci, která poskytuje pokyny, jak vyplnit prázdná pole v emailové šabloně. Prázdná pole v šabloně používané v tomto příkladu jsou name, dimension a hour.
  5. Používá SP-Lang k získání informací (!ITEM) z Baselinerem vytvořeného EVENT (podrobněji níže). V tomto případě bude pole šablony dimension vyplněno hodnotou dimension převzatou z Baselinerem vytvořeného eventu.

Spouštěč události

Můžete použít spouštěč události k vytvoření záznamu nebo události, kterou budete moci vidět v rozhraní TeskaLabs LogMan.io.

Příklad spouštěče události:

    - event: # (1)
            threat.framework: "MITRE ATT&CK"
            threat.indicator.sightings: !ITEM EVENT value
            threat.indicator.confidence: "High"
            threat.indicator.name: !ITEM EVENT dimension
  1. Tato nová událost je popis hrozby používající pole hrozby z Elasticsearch

Analýza v uživatelském rozhraní

Ve výchozím nastavení poskytuje uživatelské rozhraní LogMan.io zobrazení analýz pro user a host.

Určete analýzu ve schématu (výchozí: /Schemas/ECS.yaml) takto:

  host.id:
    type: "str"
    analysis: host

  user.id:
    type: "str"
    analysis: user

  ...

Pokud je pak nájemce nakonfigurován tak, aby používal tento schéma (ECS ve výchozím nastavení), pole host.id a user.id v Discover budou zobrazovat odkaz na danou referenční hodnotu.

Analýza host používá ve výchozím nastavení základní linii nazvanou Host:

---
define:
  name: Host

Analýza user ve výchozím nastavení používá základní linii nazvanou User:

---
define:
  name: User

Pokud konkrétní analýza nemůže najít svůj přidružený základní vzor, uživatelské rozhraní zobrazí pro tuto analýzu prázdnou obrazovku.

Poznámka

Obě základní linie potřebné pro analýzu jsou distribuovány jako součást Knihovny LogMan.io Common Library.