Threat intelligence feedy¶

Threat intelligence feedy udržují lookupy naplněné aktuálními indikátory kompromitace (IOC): IP adresy, domény, URL, hashe a podobné hodnoty. Jako analytik obvykle zvolíte, který feed plní který lookup, a pak lookup použijete v detekcích (volitelně v hodnocení rizika), aby pravidla zůstala aktuální bez hard-codování seznamů indikátorů v YAML.

Typické použití:

Watchlisty: alert při provozu nebo DNS zásahu známé špatné IP nebo domény.
Risk boost: zvýšení event.risk_score, když dimenze okna sedí na řádek IOC.
Sdílený intel: jeden udržovaný seznam pro mnoho korelačních pravidel.

Testy členství a vzory whitelist / blacklist v predikátech: Lookupy v detekcích. Jak řádky IOC mění numerické riziko: Hodnocení rizika. Typy a deklarace lookupů: reference Lookups.

Jak se feedy propojují s detekcemi¶

Cesta je vždy stejná:

Deklarace feedu v Knihovně (/Feeds/…) stahuje data podle plánu (HTTP JSON, CSV, MISP, LDAP a podobné zdroje).
Feed zapisuje položky do pojmenovaného lookupu (output.lookup).
Detekce (nebo hodnocení rizika) čte lookup pomocí !LOOKUP / !LOOKUP.CONTAINS, nebo přes skupinu lookupů ioc.

External source (TI API, MISP, LDAP, …)  →  Feed (lmio-feeds)  →  Lookup items  →  Correlator / enricher / risk score

Feed můžete připojit i z UI Lookups (feedPath). Runtime efekt je stejný: obsah lookupu se obnovuje z feedu.

Kdo za co zodpovídá

Analytici udržují které indikátory záleží (obsah lookupu a cíle feedů). Detection engineeri drží propojení predikátů stabilní. Při růstu sady indikátorů preferujte změnu feedu / lookupu místo úpravy YAML pravidla.

Předpoklady¶

Je nasazena služba LogMan.io Feeds (běží deklarace feedů).
Existuje deklarace lookupu pod /Lookups (mnoho IOC lookupů je v common library s default: true).
output.lookup feedu sedí na define.name lookupu (tenant suffix řeší platforma).
Typy klíčů sedí: IP feedy → lookup/ipaddress (nebo IP rozsah); domény → string klíče; atd.

Dodávané IOC lookupy zahrnují:

Lookup	Typický klíč	Skupina	Použití
`maliciousipaddresses`	IP	`ioc`	Špatné source / destination IP
`maliciousdomains`	doména	`ioc`	DNS a HTTP hostnames
`maliciousurls`	URL	(různé)	Shoda celé URL
`malicioushashes`	hash souboru	(různé)	Soubory / malware hashe
`torexitnodes` / `vpnexitnodes`	IP	(žádná)	Exit nodes anonymizérů

Dejte lookup do skupiny ioc, když chcete, aby Correlator risk scoring automaticky přidal skóre za shodné dimenze okna. Viz IOC a threat intelligence.

Příklad: feed plnící lookup špatných IP¶

Minimální feed čtoucí JSON seznam IP objektů a aktualizující maliciousipaddresses.

Příklad odpovědi z GET /api/v1/ips (fiktivní TI API, zkráceno). Feed iteruje results:

{
  "count": 2,
  "results": [
    {
      "ip": "203.0.113.66",
      "risk.score": 25.0,
      "tags": ["botnet", "scanner"]
    },
    {
      "ip": "198.51.100.14",
      "risk.score": 40.0,
      "tags": ["c2"]
    }
  ]
}

Mapování ve feedu níže:

iterate: results → jedna položka lookupu na objekt
key: !ITEM EVENT ip → 203.0.113.66 a 198.51.100.14 se stanou klíči v maliciousipaddresses
risk.score se uloží na položku pro hodnocení rizika; pokud chybí, feed defaultuje na 25.0
extra pole jako tags se ignorují, pokud je nepřidáte do schema / apply

---
define:
  name: Malicious IP Feed
  type: lmio/feed

  schema:
    ip: str
    risk.score: fp64

input:
  source: https://ti.example.com/api/v1/ips
  type: json
  iterate: results
  period: 1h
  headers: '{"Authorization": "Bearer {{TI_API_TOKEN}}"}'
  verify: none

apply:
  key: !ITEM EVENT ip
  risk.score:
    !TRY
    - !ITEM EVENT risk.score
    - 25.0

output:
  lookup: maliciousipaddresses

Poznámky:

period řídí, jak často se feed obnovuje (např. 1h, 1d).
key je klíč lookupu; extra pole (např. risk.score) jsou atributy pro risk scoring.
Upravte URL, hlavičky a cestu iterate podle JSON vašeho TI providera.
V hlavičkách preferujte Vault placeholdery (např. Bearer {{TI_API_TOKEN}}), aby tokeny nebyly ve sdíleném YAML Knihovny. Viz Vault placeholder pro heslo (Feeds v26.12.07+, LogMan.io v26.12.12).
Pro API s next URL na stránku použijte paginaci (subtype: pagination, pagination_mode: url). Zeptejte administrátora na zapojení.

Po běhu feedu otevřete Lookups → maliciousipaddresses a ověřte nové IP.

Příklad: CSV feed (včetně souborů bez hlavičky)¶

Mnoho TI a inventářních seznamů přichází jako CSV. Na input feedu použijte type: csv. Ve výchozím nastavení je první řádek hlavička a názvy sloupců se stanou poli události pro apply.

---
define:
  name: Malicious Domains CSV Feed
  type: lmio/feed

  schema:
    domain: str
    risk.score: fp64

input:
  source: https://ti.example.com/lists/malicious-domains.csv
  type: csv
  delimiter: ","
  period: 1d
  verify: none

apply:
  key: !ITEM EVENT domain
  risk.score:
    !TRY
    - !ITEM EVENT risk.score
    - 20.0

output:
  lookup: maliciousdomains

CSV bez hlavičky¶

Pokud soubor nemá řádek hlavičky, nastavte fieldnames na názvy sloupců v pořadí. První datový řádek se pak čte jako hodnoty, ne jako hlavičky.

input:
  source: ./data/dbip-asn-ipv4-num.csv
  type: csv
  delimiter: ","
  fieldnames:
    - start_ip
    - end_ip
    - number
    - organization.name
  period: 1d

Poznámky:

fieldnames funguje pro CSV ze souboru, HTTP a OAuth2.
Můžete předat i řetězec oddělený čárkami, např. fieldnames: "start_ip,end_ip,number".
Při vytváření feedu z UI Lookups / API šablony použijte stejný seznam jako csvFieldnames.
headers pod input jsou HTTP hlavičky požadavku, ne názvy sloupců CSV.

Po běhu feedu otevřete cílový lookup a ověřte, že klíče sedí se sloupci v fieldnames / hlavičce CSV.

Příklad: MISP feed¶

MISP (Malware Information Sharing Platform) ukládá a sdílí threat indikátory jako atributy (IP, domény, hashe, URL atd.). LogMan.io Feeds může na plán stahovat vybrané typy atributů z instance MISP a zapisovat je do IOC lookupu.

Feed vytvoříte dvěma způsoby:

UI Lookups — otevřete cílový lookup, přidejte feed, zvolte šablonu MISP (mispLines) a vyplňte formulář (MISP URL, API klíč, typy atributů, period). UI zapíše stejné YAML Knihovny jako níže.
YAML Knihovny — deklarace feedu pod /Feeds/ (příklad níže).

Co potřebujete¶

Pole	Povinné	Příklad	Význam
`source`	ano	`https://misp.example.com`	Base URL instance MISP. Feeds ji použije jako PyMISP connection URL.
`type`	ano	`misp`	Musí být `misp`, aby LogMan.io Feeds použil MISP zdroj.
`api_key`	ano	`"{{MISP_API_KEY}}"`	MISP Auth klíč (Automation key). Preferujte Vault placeholder; viz Vault placeholder pro heslo. Ve formuláři UI je to API key (`apiKey`).
`types`	ano	`ip-dst` nebo `ip-dst,ip-src`	Čárkou oddělené MISP typy atributů. Výchozí při vynechání v UI je `ip-dst`. Ve formuláři MISP types (`mispTypes`).
`period`	ano	`1h`	Jak často Feeds znovu dotazuje MISP (např. `1h`, `1d`).

Také potřeba:

LogMan.io Feeds dosáhne na MISP host (HTTPS, firewall / DNS).
Lookup, jehož typ klíče sedí na atributy, které taháte (IP → maliciousipaddresses / lookup/ipaddress; domény → maliciousdomains; hashe → malicioushashes; atd.).
MISP uživatel s Auth klíčem, který může hledat atributy zvolených typů.

Příklad: destination IP do `maliciousipaddresses`¶

---
define:
  name: MISP malicious IPs
  type: lmio/feed

  schema:
    value: str

input:
  source: https://misp.example.com
  type: misp
  period: 1h
  api_key: "{{MISP_API_KEY}}"
  types: ip-dst

apply:
  key:
    !CAST
    what: !ITEM EVENT value
    type: ip

output:
  lookup: maliciousipaddresses

Mapování:

type: misp hledá MISP atributy s type_attribute podle seznamu v types.
Každý vrácený atribut je jedna událost; indikátor je v poli value.
apply.key castuje value na ip pro IP lookup. Pro string lookupy (domény, hashe) použijte key: !ITEM EVENT value bez IP castu — UI šablona cast vybere podle typu klíče lookupu.
api_key: "{{MISP_API_KEY}}" se rozbalí z Feeds [passwords] (Vault přes Maestro). Mapujte tajemství v /Site/model.yaml stejně jako ostatní feed secrets:

services:
  lmio-feeds:
    asab:
      config:
        passwords:
          MISP_API_KEY: "{{MISP_API_KEY}}"

secrets:
  MISP_API_KEY: {}

Další typy atributů¶

Nasměrujte types (a output.lookup) na indikátory, které vás zajímají. Příklady:

Cíl	`types` (příklady)	Typický lookup
Destination / source IP	`ip-dst`, `ip-src`, nebo `ip-dst,ip-src`	`maliciousipaddresses`
Domény / hostnames	`domain`, `hostname`	`maliciousdomains`
URL	`url`	`maliciousurls`
File hashe	`md5`, `sha1`, `sha256`	`malicioushashes`

Čárkou oddělený seznam, když jeden feed táhne více souvisejících typů do stejného lookupu (např. types: domain,hostname). Oddělené feedy, když se liší typy klíčů (IP vs string).

Vytvoření z UI Lookups¶

Otevřete Lookups a vyberte cílový lookup (např. maliciousipaddresses).
Vytvořte / připojte feed a zvolte šablonu MISP.
Nastavte Source na MISP base URL, API key na "{{MISP_API_KEY}}" (nebo lab plaintext klíč), MISP types na typy atributů a Period (např. 1h).
Uložte, použijte Test pokud je k dispozici, nebo počkejte jeden period a ověřte nové klíče v lookupu.

UI generuje YAML Knihovny ekvivalentní příkladu výše (template: mispLines). Úprava YAML v Knihovně poté je volitelná.

Po běhu feedu otevřete cílový lookup a ověřte hodnoty atributů MISP jako klíče. Pak propojte detekce jako v sekcích níže (členství / ioc risk).

Příklad: alert při provozu na IOC IP¶

Stejný vzor jako jiné watchlisty v Lookupy v detekcích: členství source.ip v lookupu.

predicate:
  !AND
  - !IN
    what: source.ip
    where: !EVENT
  - !IN
    what: !ITEM EVENT source.ip
    where:
      !LOOKUP
      what: maliciousipaddresses

trigger:
  - event:
      source.ip: !ITEM EVENT source.ip
      destination.ip: !ITEM EVENT destination.ip
      threat.indicator.confidence: high
      threat.indicator.ip: !ITEM EVENT source.ip
      threat.indicator.type: malicious_ip

Pravidla Knihovny jako Traffic from Tor Exit Nodes používají stejnou idea s torexitnodes místo maliciousipaddresses. Nasměrujte feed na torexitnodes (nebo držte vlastní Tor seznam) a dodávané pravidlo začne matchovat, jakmile položky přistanou v lookupu.

Zkratka¶

- !LOOKUP.CONTAINS
  what: !ITEM EVENT source.ip
  in: maliciousipaddresses

Příklad: špatné domény a DNS¶

Feed zapisuje hostnames do maliciousdomains (string klíče).
Pravidlo testuje dns.question.name (nebo url.domain podle parserů).

predicate:
  !AND
  - !IN
    what: dns.question.name
    where: !EVENT
  - !IN
    what: !ITEM EVENT dns.question.name
    where:
      !LOOKUP
      what: maliciousdomains

Slaďte klíč feedu s polem události (FQDN vs holá doména). Normalizujte v sekci apply feedu, pokud TI zdroj a DNS logy používají různé formáty.

Příklad: zvýšení rizika bez vlastního pravidla¶

Pokud je lookup ve skupině ioc, Correlator může přičíst risk.score z odpovídajících řádků, když dimenze okna detekce obsahují tuto hodnotu (např. source.ip nebo dns.question.name). Pro tento boost nepotřebujete samostatné pravidlo „IOC hit“.

key              risk.score
203.0.113.66     25.0
evil.example.com 20.0

Pravidlo selhání VPN se základním skóre 45, jehož source.ip sedí na první řádek, má 70 před váhou aktiva. Detaily: Hodnocení rizika.

Explicitní watchlist pravidlo (předchozí sekce) stále použijte, když chcete dedikovaný alert za každé zahlédnutí IOC, ne jen bump skóre na jiných detekcích.

Kontrolní seznam zapojení¶

Lookup existuje a má správný typ (ip, string atd.).
Volitelně: group: ioc v deklaraci lookupu pro automatické přičtení rizika.
Feed output.lookup rovná se názvu lookupu.
Feed key / schema sedí na klíče lookupu; v apply castujte typy podle potřeby.
Detekce používá !LOOKUP / !LOOKUP.CONTAINS na stejný název, nebo spoléháte jen na ioc risk.
Po nasazení počkejte jeden period feedu, ověřte položky v UI a test událost v Discover.

Praktické tipy¶

Preferujte jeden feed na lookup (nebo jasnou merge strategii), aby vlastnictví bylo zřejmé.
Držte základní severity pravidla poctivě; IOC risk.score a ladění pravidel použijte k prioritizaci bez přepisování predikátů.
Globální lookupy / feedy pro sdílený intel napříč tenanty; tenant-scoped pro lokální nebo zákaznické seznamy.
Nevkládejte velké statické IOC seznamy do korelačního YAML; k tomu jsou feedy a lookupy.
Při testu vložte jednu známou test IP nebo doménu do lookupu (UI nebo feed), pošlete syntetickou událost, pak testovací řádek odstraňte.

Pokročilý příklad: Netbox prefixy jako obohacení¶

Ne každý feed je klasický IOC watchlist. Stejná cesta feed → lookup může udržovat inventář aktuální a znovu ho použít v obohacení při parsování a v detekcích. Běžný případ jsou Netbox IPAM prefixy: každý prefix je CIDR s volitelným VLAN a popisem; feed ukládá do lookupu IP rozsah; Parsec pak taguje události podle source.ip.

1. IP rozsahový lookup¶

Deklarujte lookup se dvěma IP klíči (start, end) a atributy, které chcete na události:

---
define:
  type: lookup/ipaddressrange
  name: netbox
  label: Netbox prefixes
  description_title: Prefixes and VLANs from Netbox IPAM

keys:
  - name: start
    type: ip
  - name: end
    type: ip

fields:
  prefix:
    type: str
  description:
    type: str
  vlan.id:
    type: str
  vlan.name:
    type: str
  status:
    type: str

2. Feed stránkující Netbox a rozbalující CIDR klíče¶

Netbox (a podobná Django REST API) vrací absolutní URL next. Použijte pagination_mode: url. Klíč feedu je CIDR řetězec (prefix); LogMan.io Feeds ho rozbalí na start / end pro IP rozsahový lookup.

Příklad odpovědi z GET /api/ipam/prefixes/?limit=100 (zkráceno). Feed iteruje results a sleduje next, dokud není null:

{
  "count": 2,
  "next": "https://netbox.example.com/api/ipam/prefixes/?limit=100&offset=100",
  "previous": null,
  "results": [
    {
      "id": 42,
      "prefix": "10.0.112.0/22",
      "description": "Office LAN Prague",
      "status": {
        "value": "active",
        "label": "Active"
      },
      "vlan": {
        "id": 7,
        "vid": 112,
        "name": "OFFICE-PRG"
      }
    },
    {
      "id": 43,
      "prefix": "10.0.200.0/24",
      "description": "Guest WiFi",
      "status": {
        "value": "active",
        "label": "Active"
      },
      "vlan": null
    }
  ]
}

Mapování ve feedu níže:

iterate: results → jedna položka lookupu na objekt prefixu
pagination_path: next → URL druhé stránky výše; poslední stránka má "next": null
key: !ITEM EVENT prefix → např. 10.0.112.0/22 se stane rozsahem 10.0.112.0 … 10.0.115.255
vnořené vlan.vid / vlan.name a status.label přes vnořené !GET; když je vlan null, !TRY uloží prázdný řetězec

---
define:
  name: Netbox Prefixes Feed
  type: lmio/feed

  schema:
    prefix: str
    description: str
    vlan: "(id: si64, vid: si64, name: str)"
    status: "(value: str, label: str)"

input:
  source: https://netbox.example.com/api/ipam/prefixes/?limit=100
  type: json
  subtype: pagination
  pagination_path: next
  pagination_mode: url
  iterate: results
  period: 1d
  headers: '{"Authorization": "Bearer {{NETBOX_TOKEN}}"}'
  verify: none

apply:
  key: !ITEM EVENT prefix

  prefix:
    !CAST
    what: !ITEM EVENT prefix
    type: str

  description:
    !TRY
    - !CAST
      what: !ITEM EVENT description
      type: str
    - ""

  vlan.id:
    !TRY
    - !CAST
      what:
        !GET
        from:
          !GET
          from: !EVENT
          what: vlan
        what: vid
      type: str
    - ""

  vlan.name:
    !TRY
    - !CAST
      what:
        !GET
        from:
          !GET
          from: !EVENT
          what: vlan
        what: name
      type: str
    - ""

  status:
    !TRY
    - !CAST
      what:
        !GET
        from:
          !GET
          from: !EVENT
          what: status
        what: label
      type: str
    - ""

output:
  lookup: netbox

Vnořené Netbox objekty (vlan, status) potřebují vnořené !GET (ne ploché !ITEM EVENT vlan.vid). Chybějící VLAN řeší !TRY a prázdný řetězec. Šablona tohoto feedu je pod /Templates/Feeds/ v common library.

3. Enricher: mapování `source.ip` na ECS pole¶

Po naplnění lookupu Parsec enricher může najít rozsah obsahující source.ip a zapsat ECS pole jako source.vlan.id, source.vlan.name, source.subnet.id a network.name. Enricher dejte do parser chain po mapování, aby source.ip už existovalo.

---
define:
  type: parsec/enricher
  schema: /Schemas/ECS.yaml

enrich:
  source.vlan.id:
    !OR
    - !GET
      what: vlan.id
      from:
        !GET
        from:
          !LOOKUP
          what: netbox
        what: !ITEM EVENT source.ip
    - !ITEM EVENT source.vlan.id

  source.vlan.name:
    !OR
    - !GET
      what: vlan.name
      from:
        !GET
        from:
          !LOOKUP
          what: netbox
        what: !ITEM EVENT source.ip
    - !ITEM EVENT source.vlan.name

  source.subnet.id:
    !OR
    - !GET
      what: prefix
      from:
        !GET
        from:
          !LOOKUP
          what: netbox
        what: !ITEM EVENT source.ip
    - !ITEM EVENT source.subnet.id

  network.name:
    !OR
    - !GET
      what: description
      from:
        !GET
        from:
          !LOOKUP
          what: netbox
        what: !ITEM EVENT source.ip
    - !ITEM EVENT network.name

!OR zachová existující hodnotu, když lookup mine (neznámá nebo veřejná IP). Stejný vzor funguje pro destination.ip nebo client.ip s paralelními bloky.

Schema auto enrich

ECS také dokumentuje automatické obohacení z lookupu subnets do source.vlan.id / source.subnet.id. Pokud lookup pojmenujete subnets a slaďte názvy polí, Parsec může tyto dvě pole naplnit bez vlastního enricheru. Enricher výše je pro lookup pojmenovaný netbox a extra pole jako source.vlan.name a network.name.

4. Volitelně: detekce na obohacených nebo raw lookup datech¶

Po obohacení mohou pravidla filtrovat source.vlan.id nebo network.name jako jakékoli jiné ECS pole. Členství v rozsahovém lookupu můžete testovat přímo (stejný styl jako zóny):

- !IN
  what: !ITEM EVENT source.ip
  where:
    !LOOKUP
    what: netbox

Užitečné pro pravidla stylu „provoz z Netbox spravovaného prefixu“, zatímco enricher drží Discover a dashboardy čitelné bez opakování lookupu v každém dotazu.

Pokročilý příklad: Active Directory SID na user ID¶

Feedy nejsou omezeny na threat intel API. LDAP feed může synchronizovat účty z Active Directory do lookupu, aby parsery a detekce řešily Windows SID na usernames.

Common library dodává lookup sids2userid (group: asset) a Windows Event Log enrichery mapující we.user.security.id (a podobná SID pole) přes lookup na user.name / související identity pole.

1. Lookup¶

sids2userid používá string SID jako klíč a ukládá user.id (typicky sAMAccountName):

---
define:
  type: lookup/string
  name: sids2userid
  label: Security Identifiers to User ID
  group: asset
  description_title: List of user security identifiers to user IDs
  default: true

keys:
  - name: sid
    type: str

fields:
  user.id:
    type: str

2. LDAP feed¶

Feed se binduje na domain controller, hledá user objekty, převádí binární objectSid pomocí !LDAP.SID a zapisuje každý řádek do sids2userid.

Nahraďte host, bind účet, base DN a název tajemství pro vaše prostředí. Preferujte Vault placeholder v password, aby YAML Knihovny neukládal bind heslo.

Zabezpečení bind hesla Vaultem¶

Dostupnost

Vyžaduje LogMan.io Feeds v26.12.07 nebo novější (LogMan.io v26.12.12). Viz LDAP / AD: Vault placeholder pro heslo.

Uložte heslo do Vaultu (na hostu LogMan.io):

curl -X PUT localhost:8891/vault/LDAP_USER_PASSWORD --data 'supersecret'

Namapujte na Feeds v /Site/model.yaml, pak aplikujte:

services:
  lmio-feeds:
    asab:
      config:
        passwords:
          LDAP_USER_PASSWORD: "{{LDAP_USER_PASSWORD}}"

secrets:
  LDAP_USER_PASSWORD: {}

Ve feedu použijte password: "{{LDAP_USER_PASSWORD}}" (viz příklad níže).

Úplný postup krok za krokem (včetně alternativní syntaxe a řešení problémů) je v LDAP / AD feed identity uživatele: Použití Vault placeholderu pro heslo.

---
define:
  name: Sids to User ID Feed
  type: lmio/feed
  # Define schema from the input fields loaded by the feed
  schema:
    objectSid: binary
    sAMAccountName: str

input:
  source: ldap://10.84.203.57
  type: ldap
  username: adldap@domain.int
  password: "{{LDAP_USER_PASSWORD}}"
  base: dc=DOMAIN,dc=int
  filter: (&(objectCategory=person)(objectClass=user))
  attributes: objectSid sAMAccountName
  period: 1h

apply:
  key:
    !LDAP.SID
    what: !ITEM EVENT objectSid

  user.id:
    !CAST
    what: !ITEM EVENT sAMAccountName
    type: str

output:
  lookup: sids2userid

Mapování:

type: ldap tahá záznamy z Active Directory při každém period (1h výše).
password: "{{…}}" rozbalí bind heslo z Feeds [passwords] (Vault přes Maestro); neukládejte plaintext hesla do sdílených feedů Knihovny.
filter vybírá person/user objekty; attributes omezuje vrácené LDAP atributy.
!LDAP.SID převede binární objectSid na string SID jako klíč lookupu.
user.id ukládá sAMAccountName jako atribut lookupu (stejný název jako v deklaraci lookupu).

Po běhu feedu otevřete Lookups → sids2userid a ověřte páry SID → username.

3. Obohacení a detekce¶

Windows parsery v common library už používají sids2userid (např. SID → user.name). Jakmile feed drží lookup aktuální, obohacené události ukazují názvy účtů, i když raw log nesl jen SID.

Pro mapování display names (nebo jiných username řetězců) na kanonické user.id přes usernames2userid viz LDAP / AD feed identity uživatele.

V detekcích můžete testovat členství nebo řešit identitu stejně jako u jiných lookupů (viz Lookupy v detekcích). Držte period feedu dost krátké pro churn nástupů a odchodů v AD.

Související čtení¶

Lookupy v detekcích: whitelist a blacklist predikáty
LDAP / AD feed identity uživatele: plnění usernames2userid z Active Directory
LDAP / AD: Vault placeholder pro heslo: bind hesla (a MISP API klíče) mimo YAML Knihovny
Tools: MISP: MISP jako integrovaný nástroj LogMan.io
Hodnocení rizika: skupina IOC a vrstvy skóre
Predikáty: SP-Lang filtry
Deklarace enricherů: přidávání polí při parsování
Reference Lookups: typy, deklarace, nasazení
IP address lookups: IP a IP rozsahové lookupy
Pokročilá korelační pravidla: vícestupňová pravidla konzumující threat intel signály

Threat intelligence feedy¶

Jak se feedy propojují s detekcemi¶

Předpoklady¶

Příklad: feed plnící lookup špatných IP¶

Příklad: CSV feed (včetně souborů bez hlavičky)¶

CSV bez hlavičky¶

Příklad: MISP feed¶

Co potřebujete¶

Příklad: destination IP do maliciousipaddresses¶

Další typy atributů¶

Vytvoření z UI Lookups¶

Příklad: alert při provozu na IOC IP¶

Zkratka¶

Příklad: špatné domény a DNS¶

Příklad: zvýšení rizika bez vlastního pravidla¶

Kontrolní seznam zapojení¶

Praktické tipy¶

Pokročilý příklad: Netbox prefixy jako obohacení¶

1. IP rozsahový lookup¶

2. Feed stránkující Netbox a rozbalující CIDR klíče¶

3. Enricher: mapování source.ip na ECS pole¶

4. Volitelně: detekce na obohacených nebo raw lookup datech¶

Pokročilý příklad: Active Directory SID na user ID¶

1. Lookup¶

2. LDAP feed¶

Zabezpečení bind hesla Vaultem¶

3. Obohacení a detekce¶

Související čtení¶

Příklad: destination IP do `maliciousipaddresses`¶

3. Enricher: mapování `source.ip` na ECS pole¶