Sikkerhetshendelser (SIEM)

Status200 lagrer sikkerhetshendelser ved siden av loggene, trasene og metrikkene dine, og gir alle samme form, OCSF (Open Cybersecurity Schema Framework), uansett hvilket format de kom i. Send hendelser fra hvilken som helst kilde, søk i dem, og finn de viktige med Sigma-deteksjonsregler, trusseletterretning og monitorer. Det de finner, blir saker som skal behandles, og playbooks reagerer på dem.

Slik fungerer det#

Åpne Produkter → Security Events, under Observerbarhet. Menyen har en seksjon for hver del av sikkerheten, og en egen side for hver ting i den:

Detections, KI og Connections, som settes opp én gang, er slått sammen til du åpner dem. Ny med sikkerhet? Kom i gang med sikkerhet setter det opp med to klikk.

Før du begynner#

Sikkerhetsdata kan bare leses av rollene Project Owner og Project Admin og av de tre Security-rollene; andre roller ser ingenting i Security Events. Se Roller.

Send sikkerhetshendelser#

1. Opprett en ingestion-nøkkel#

   Åpne Prosjektinnstillinger → Telemetri og APM → Inntaksnøkler, og klikk på Opprett ingestion-nøkkel. Sikkerhetshendelser bruker de samme nøklene som resten av telemetrien din.

2. Send hendelsene dine#

   Send JSON til /security-events/v1/ingest med nøkkelen i x-status200-token:

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   Endepunktet svarer 200 så snart hendelsene står i kø. En hendelse sendt uten tidspunkt, som disse, plasseres i øyeblikket den kommer inn.

3. Finn dem under Hendelser#

   Åpne Produkter → Security Events → Hendelser. Hendelsene vises i løpet av noen sekunder, med alvorlighetsgrad, klasse, bruker, vert og IP-adresser fylt ut.

Formater#

Angi formatet med ?format=, med hodet x-oneuptime-security-event-format eller med et felt "format" på øverste nivå. Utelater du det, bestemmes formatet for hver hendelse for seg, så én webhook kan blande deteksjoner med rå hendelser.

• Body kan være én hendelse, en matrise av hendelser eller { "events": [...] }.
• Hodet x-status200-service-name angir telemetritjenesten hendelsene hører til. Uten det hører de til tjenesten som er oppkalt etter produktet eller leverandøren til den første hendelsen, eller til Security Events.
• Ingenting forkastes fordi det ikke lot seg tilordne: hvert felt fra kilden havner i hendelsens attributter.

Felt i generisk JSON#

En generisk hendelse leses ut fra vanlige feltnavn:

Et ord for alvorlighetsgrad blir et OCSF-nivå: info leses som Informational, warning som Low, error som Medium, alert som Critical og emergency som Fatal.

Videresend med Fluent Bit#

For å sende sikkerhetslogger du allerede samler inn, for eksempel auditd, syslog eller Falco, legger du til en http-utgang i Fluent Bit:

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

Siden Oppsettveiledning, under Connections, har disse kodesnuttene med din egen vert og nøkkel fylt ut.

Finn sikkerhetshendelser i loggene dine#

Kortet Loggene dine, øverst på Connections, gjør loggene du allerede sender til Status200, til en kilde. Med Finn sikkerhetshendelser i loggene dine slått på leses prosjektets nye logger hvert minutt, og hver SSH-pålogging, sudo-kommando, Kubernetes-revisjonsoppføring, AWS CloudTrail-endring og hvert webangrep i dem lagres som en sikkerhetshendelse. Se Kom i gang med sikkerhet for hva hver type dekker.

Koble til et sikkerhetsprodukt#

Connections henter data fra et sikkerhetsprodukt for deg og importerer de nye postene som sikkerhetshendelser. En tilkobling inneholder produktets innstillinger og en kryptert legitimasjon; en worker henter fra den med intervallet du angir, og hopper over poster den allerede har importert.

• Produktets egne varsler på eller over Open Cases From (Høy og høyere med mindre du velger et annet nivå, eller Aldri) åpner saker, gruppert etter brukeren, verten eller adressen de gjelder.
• En tilkobling leser poster etter tidspunktet produktet opprettet dem, ikke etter tidspunktet for aktiviteten de beskriver. En SIEM-regel som kjører hver time, oppretter deteksjoner lenge etter hendelsene den traff, og de importeres likevel.
• Den første hentingen ser 24 timer tilbake, så en ny tilkobling viser nylige poster med en gang.
• Test tilkoblingen, i tilkoblingens rad, sjekker tilgangen til produktet og at Status200s egne workers kjører, og importerer ingenting. Run now henter med en gang.

Hva en hendelse inneholder#

Hver hendelse lagres med typede felt og kildens nyttelast:

Utforsk sikkerhetshendelser#

Hendelser er en telemetriutforsker som utforskerne for logger og traser: et diagram over vinduets hendelser etter alvorlighetsgrad, et sidepanel med fasetter, listen, og et panel med hvert felt og attributt i hendelsen du åpner. Vinduet, filtrene og søket ligger alle i URL-en, så en filtrert visning kan deles og overlever en ny innlasting.

Søk#

Søkefeltet snakker samme språk som de andre telemetriutforskerne (se Søkesyntaks):

Et felt er enten et kort navn (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) eller feltets eget navn, for eksempel severityName eller principalHost. Alle andre navn leses som et kildeattributt. observable:<value> finner hver hendelse som nevner en verdi, uansett hvilken side av aktiviteten den var på.

Fasetter#

Sidepanelet teller vinduets hendelser etter Kilde, Alvorlighetsgrad, Hendelsesklasse, Category, Aktivitet, Status, Leverandør, Produkt, Detection Rule, Kildebruker, Kildevert, Prosess og Overordnet prosess. Klikk på en verdi for å beholde bare hendelsene med den, eller på minustegnet ved siden av for å utelate dem. Klikk igjen for å angre. Diagrammet og hver telling beskriver nøyaktig hendelsene i listen.

Korreler#

Korreler tegner hendelsene rundt en vert, en bruker eller en IP-adresse: hendelsesklassene deres rundt det du søkte etter, merket med den verste alvorlighetsgraden, og de andre verdiene fra de samme hendelsene på den ytre ringen. Klikk på en klasse for å liste hendelsene i den, eller på en verdi for å korrelere på den neste gang. Hver observable i panelet til en hendelse under Hendelser åpner Korreler på den.

Deteksjonsregler#

En deteksjonsregel er en Sigma-regel, et åpent YAML-format for å beskrive mistenkelig aktivitet, som Status200 kjører etter en tidsplan mot hendelsene dine. Når den treffer, åpner den en sak eller legger treffet til i en åpen sak, åpner et varsel, eventuelt en hendelse (incident), og skriver et Detection Finding tilbake blant sikkerhetshendelsene. Rule Library har ferdige regler å starte fra.

Opprett en regel#

En første regel, som treffer mislykkede pålogginger fra utenfor 10.x.x.x:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

Hva en regel kan uttrykke#

Status200 kjører den boolske kjernen i Sigma:

• Seleksjoner er feltkart (hvert felt må treffe; en liste med verdier treffer hvilken som helst av dem) eller nøkkelordlister, som treffer hvor som helst i meldingen.
• Betingelser kombinerer seleksjoner med and, or, not og parenteser, eller med 1 of selection_*, all of selection_*, any of them og all of them.
• Feltmodifikatorer: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists og windash. Tekst sammenlignes uten hensyn til store og små bokstaver, med mindre du legger til cased.
• Et felt er et typet felt (principalUser), en vanlig Sigma-skrivemåte av et (CommandLine, src_ip, Hostname), eller hvilken som helst attributtnøkkel, skrevet slik den er i hendelsen (threat.matched).
• Image og CommandLine leser prosessen hendelsen handler om, ved en prosessoppstart den som startet (processPath, processCommandLine), og ParentImage og ParentCommandLine prosessen som startet den (parentProcessPath, parentProcessCommandLine). principalProcess er prosessen som handlet, som ved en oppstart er den overordnede.
• level angir alvorlighetsgraden: informational, low, medium, high eller critical, og medium når den mangler. ATT&CK-ID-er i tags (attack.t1110, attack.ta0006) fyller ut funnets MITRE-felt.

Aggregeringer som | count() by principalIp > 5 avvises når du lagrer: bruk en korrelasjonsregel, eller Group By Field og Match Count Threshold, i stedet. logsource er bare informativ og snevrer ikke inn noe: legg det filteret i en seleksjon, for eksempel className: Authentication. En timeframe ignoreres, fordi regelens intervall bestemmer vinduet.

Korrelasjonsregler#

En Sigma-korrelasjon utløses av flere hendelser sammen i stedet for én. Lim den inn i Sigma Rule (YAML) sammen med reglene den leser, som YAML-dokumenter atskilt med ---, eller navngi regler prosjektet allerede har, med Sigma-name eller -id. Rule Library har ferdige, for eksempel mislykkede pålogginger fulgt av en vellykket.

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• En gruppe er verdien av feltene i group-by, for eksempel én adresse. Tellinger er rullerende: et utbrudd som to kjøringer deler, telles likevel helt innenfor sitt timespan, som er høyst 24 timer.
• new_value er Status200s egen type, siden Sigma ikke har noen korrelasjon for "sett første gang": den sammenligner med opptil 30 dagers historikk. value_sum, value_avg, value_percentile og value_median avvises når du lagrer.
• Kolonnen Type i Detection Rules viser hver regels type, og skjemaet sier i én setning hva regelen ser etter.

Evalueringsinnstillinger#

Group By og Distinct Count tar de samme feltnavnene som regelen. Med dem sier terskelen «så mange, fra den samme tingen, i én kjøring», uten en monitor på toppen:

Når en regel kjører#

Status200 sjekker hvert minutt etter aktiverte regler der intervallet har gått siden forrige kjøring. Hver kjøring leser hendelsene der hendelsestidspunktet ligger mellom forrige kjøring og for to minutter siden, og går deretter videre. De to minuttene gir rom for hendelser som fortsatt er på vei, for eksempel en logglinje som leses et minutt etter at den ble skrevet:

• Vinduene ligger etter hverandre og glir ikke. Med et intervall på 10 minutter kan feil kl. 09:58 og 10:01 havne i ulike kjøringer og telles hver for seg, så legg inn margin når du velger en terskel.
• Etter et opphold, for eksempel et worker-avbrudd eller en regel som er slått på igjen, dekker neste kjøring hele oppholdet, opptil de siste 24 timene.
• En hendelse som kommer mer enn to minutter for sent, etter at en kjøring har dekket tidspunktet, lagres og er søkbar, men den regelen leser den aldri.
• Hver gruppe som når terskelen, blir et Detection Finding, opptil 10 000 per kjøring. Varsler, hendelser og saker åpnes for de 100 med høyest telling; resten deler én sak om regelen, og regelens Siste feil sier hvor mange grupper som traff.

Alvorlighetsgrad#

Regelens level er alvorlighetsgraden til funnene: informational, low, medium, high og critical blir Informational, Low, Medium, High og Critical. Varslene og hendelsene (incidents) får en av prosjektets alvorlighetsgrader, i denne rekkefølgen:

1. Regelens Varselsalvor (eller Hendelsesalvor), når den er angitt.
2. Alvorlighetsgraden din som er oppkalt etter nivået, for eksempel High, uansett store og små bokstaver.
3. Etter rang: regler med critical og high får den alvorligste alvorlighetsgraden din, de andre den minst alvorlige.

Varsler og funn#

Hver gruppe som slår til, åpner et varsel med tittelen [Detection] <rule name> — <group value>, eller [Detection] <rule name> for en regel uten Group By Field. Så lenge det er åpent, åpner nye treff for den gruppen ikke et nytt. En regel ser bare treff og kan ikke se at et angrep har stoppet, så varslene forblir åpne til noen løser dem.

Et Detection Finding er en sikkerhetshendelse av klassen Detection Finding (OCSF-klasse 2004) fra produktet Status200 Detections, med regelens MITRE-tagger, gruppeverdien først i observables, og disse attributtene:

Funn er vanlige hendelser: søk etter dem under Hendelser og pivoter på dem i Korreler. For å prøve ut en ny regel i det stille slår du av alle handlinger unntatt funnet til du stoler på den.

Monitorer for sikkerhetshendelser#

En monitor for sikkerhetshendelser teller hendelsene som treffer filtrene, over et glidende vindu, og kjører de vanlige monitorkriteriene på tellingen: den endrer monitorens status, åpner varsler eller hendelser (incidents), og varsler vakthavende. Opprett en under Overvåkere → Opprett monitor, med Security Events som type; den vises der sammen med de andre monitorene dine.

Skjemaet viser Monitor events that include this text, Monitor Security Events for (time), Event Severity og Hendelsesklasse. Filtrer etter telemetritjeneste og Filtrer etter attributter venter under Flere felt, der overskriften viser hvilke en monitor bruker. Kriteriene sjekker Security Event Count.

Skriv selve deteksjonen som en regel, med terskelen sin. Bruk en monitor når du vil ha et glidende vindu, en status som hentes inn igjen av seg selv, en statusside eller ulike vaktpolicyer per kriterium.

Følg med på deteksjonene dine#

Funn er hendelser, så en monitor kan følge med på selve reglene:

• Stormer: en monitor på klassen Detection Finding, som teller hvert funn. Tjue ulike regler som slår til i løpet av en time, er et signal ingen enkeltregel kan se.
• Endringer i takt: filtrer på status200.detection.rule_id for én regel. En regel som slår til ukentlig og plutselig slår til femti ganger i timen, trenger en annen respons.
• Stillhet: funn som faller til null når du vanligvis ser noen få, betyr som regel at en kilde har sluttet å sende. Bruk et kriterium som sjekker for en telling under et tall.

Handlingen Opprett monitor i raden til en regel åpner en ny monitor som allerede er satt opp slik: klassen Detection Finding, regelens ID (aldri navnet, som et nytt navn ville endre), og den siste timen. En slik monitor teller funn, ett per gruppe per kjøring, ikke hendelsene bak dem. For å kreve et antall hendelser før noe slår til, bruker du regelens Match Count Threshold.

Trusseletterretning#

Threat Intel abonnerer på STIX/TAXII-feeder med kjente ondsinnede IP-adresser, domener, URL-er, e-postadresser og filhasher. Hendelser som nevner en av dem, merkes med threat.*-attributter når de kommer inn, som regler og monitorer kan filtrere på, og hvert minutt sammenlignes nylige hendelser med feedene, noe som åpner varsler og funn slik en regel gjør. Se Trusseletterretning.

Oppbevaring og fakturering#

Sikkerhetshendelser faktureres per GB som tas inn, som resten av telemetrien din, og oppbevares i telemetriens oppbevaringstid: prosjektets Standard oppbevaring (dager), under Prosjektinnstillinger → Telemetri og APM → Dataoppbevaring, eller en oppbevaringstid som er angitt på telemetritjenesten de hører til. Når oppbevaringstiden for en hendelse er ute, slettes den.

Feilsøking#

Neste steg#