Sikkerhedsbegivenheder (SIEM)

Status200 gemmer sikkerhedsbegivenheder ved siden af dine logs, traces og metrikker og giver dem alle den samme form, OCSF (Open Cybersecurity Schema Framework), uanset hvilket format de ankom i. Send begivenheder fra en hvilken som helst kilde, søg i dem, og find de vigtige med Sigma-detektionsregler, trusselsintelligens og monitorer. Det, de finder, bliver til sager, der skal behandles, og playbooks reagerer på dem.

Sådan virker det#

Åbn Produkter → Security Events under Observabilitet. Menuen har en sektion for hver del af sikkerheden og en side for sig for hver ting i den:

Detections, AI og Connections, som sættes op én gang, forbliver foldet sammen, indtil du åbner dem. Ny i sikkerhed? Kom godt i gang med sikkerhed sætter det op med to klik.

Før du begynder#

Sikkerhedsdata kan kun læses af rollerne Project Owner og Project Admin og af de tre Security-roller; andre roller ser intet i Security Events. Se Roller.

Send sikkerhedsbegivenheder#

1. Opret en ingestion-nøgle#

   Åbn Projektindstillinger → Telemetri og APM → Indtagelsesnøgler, og klik på Opret ingestion-nøgle. Sikkerhedsbegivenheder bruger de samme nøgler som resten af din telemetri.

2. Send dine begivenheder#

   Send JSON til /security-events/v1/ingest med nøglen 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" } ] }'

   Endpointet svarer 200, når begivenhederne står i kø. En begivenhed uden tidspunkt, som disse, placeres i det øjeblik, den ankommer.

3. Find dem under Begivenheder#

   Åbn Produkter → Security Events → Begivenheder. Begivenhederne vises inden for få sekunder med deres alvorlighed, klasse, bruger, vært og IP-adresser udfyldt.

Formater#

Angiv formatet med ?format=, med headeren x-oneuptime-security-event-format eller med et felt "format" på øverste niveau. Udelader du det, bestemmes hver begivenheds format for sig, så én webhook kan blande detektioner med rå begivenheder.

• Brødteksten kan være én begivenhed, et array af begivenheder eller { "events": [...] }.
• Headeren x-status200-service-name angiver den telemetritjeneste, begivenhederne hører til. Uden den hører de til den tjeneste, der er opkaldt efter den første begivenheds produkt eller leverandør, eller til Security Events.
• Intet kasseres, fordi det ikke kunne tilknyttes: hvert felt fra kilden havner i begivenhedens attributter.

Felter i generisk JSON#

En generisk begivenhed læses ud fra almindelige feltnavne:

Et ord for alvorlighed bliver et OCSF-niveau: info læses som Informational, warning som Low, error som Medium, alert som Critical og emergency som Fatal.

Videresend med Fluent Bit#

For at sende sikkerhedslogs, du allerede indsamler, f.eks. auditd, syslog eller Falco, tilføjer du et http-output til 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 Opsætningsvejledning, under Connections, har disse kodestykker med din egen vært og nøgle udfyldt.

Find sikkerhedshændelser i dine logs#

Kortet Dine logs, øverst på Connections, gør de logs, du allerede sender til Status200, til en kilde. Med Find sikkerhedshændelser i dine logs slået til læses projektets nye logs hvert minut, og hvert SSH-login, hver sudo-kommando, hver Kubernetes-auditpost, hver AWS CloudTrail-ændring og hvert webangreb i dem gemmes som en sikkerhedshændelse. Se Kom godt i gang med sikkerhed for, hvad hver slags dækker.

Forbind et sikkerhedsprodukt#

Connections henter data fra et sikkerhedsprodukt for dig og importerer dets nye poster som sikkerhedsbegivenheder. En forbindelse indeholder produktets indstillinger og en krypteret legitimation; en worker henter fra den med det interval, du angiver, og springer poster over, som den allerede har importeret.

• Produktets egne advarsler på eller over Open Cases From (Høj og højere, medmindre du vælger et andet niveau, eller Aldrig) åbner sager, grupperet efter den bruger, vært eller adresse, de handler om.
• En forbindelse læser poster efter det tidspunkt, produktet oprettede dem, ikke efter tidspunktet for den aktivitet, de beskriver. En SIEM-regel, der kører hver time, opretter detektioner længe efter de begivenheder, den matchede, og de importeres alligevel.
• Den første hentning kigger 24 timer tilbage, så en ny forbindelse viser nylige poster med det samme.
• Test forbindelse i forbindelsens række tjekker adgangen til produktet, og at Status200s egne workers kører, og importerer intet. Run now henter med det samme.

Hvad en begivenhed indeholder#

Hver begivenhed gemmes med typede felter og kildens payload:

Udforsk sikkerhedsbegivenheder#

Begivenheder er en telemetrioversigt ligesom oversigterne for logs og traces: et diagram over vinduets begivenheder efter alvorlighed, en sidebjælke med facetter, listen og et panel med hvert felt og hver attribut i den begivenhed, du åbner. Vinduet, filtrene og søgningen ligger alle i URL'en, så en filtreret visning kan deles og overlever en genindlæsning.

Søgning#

Søgefeltet taler det samme sprog som de andre telemetrioversigter (se Søgesyntaks):

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, f.eks. severityName eller principalHost. Alle andre navne læses som en kildeattribut. observable:<value> finder hver begivenhed, der nævner en værdi, uanset hvilken side af aktiviteten den var på.

Facetter#

Sidebjælken tæller vinduets begivenheder efter Kilde, Alvorlighed, Begivenhedsklasse, Category, Aktivitet, Status, Leverandør, Produkt, Detection Rule, Kildebruger, Kildevært, Proces og Overordnet proces. Klik på en værdi for kun at beholde dens begivenheder, eller på minusset ved siden af for at udelade dem. Klik igen for at fortryde. Diagrammet og hver optælling beskriver præcis begivenhederne på listen.

Korrelér#

Korrelér tegner begivenhederne omkring en vært, en bruger eller en IP-adresse: deres begivenhedsklasser omkring det, du søgte efter, markeret med deres værste alvorlighed, og de andre værdier fra de samme begivenheder på den ydre ring. Klik på en klasse for at vise dens begivenheder, eller på en værdi for at korrelere på den næste gang. Hver observable i en begivenheds panel under Begivenheder åbner Korrelér på den.

Detektionsregler#

En detektionsregel er en Sigma-regel, et åbent YAML-format til at beskrive mistænkelig aktivitet, som Status200 kører efter en tidsplan mod dine begivenheder. Når den matcher, åbner den en sag eller føjer matchet til en åben sag, åbner en advarsel, eventuelt en hændelse, og skriver et Detection Finding tilbage i begivenhederne. Rule Library har færdige regler at starte fra.

Opret en regel#

En første regel, der matcher mislykkede logins uden for 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

Hvad en regel kan udtrykke#

Status200 kører den boolske kerne af Sigma:

• Selektioner er feltkort (hvert felt skal matche; en liste af værdier matcher en hvilken som helst af dem) eller nøgleordslister, der matcher hvor som helst i beskeden.
• Betingelser kombinerer selektioner 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 uden hensyn til store og små bogstaver, medmindre du tilføjer cased.
• Et felt er et typet felt (principalUser), en almindelig Sigma-stavemåde af et (CommandLine, src_ip, Hostname) eller en hvilken som helst attributnøgle, stavet som i begivenheden (threat.matched).
• Image og CommandLine læser den proces, som begivenheden handler om, ved en processtart den, der startede (processPath, processCommandLine), og ParentImage og ParentCommandLine den proces, der startede den (parentProcessPath, parentProcessCommandLine). principalProcess er den proces, der handlede, hvilket ved en processtart er den overordnede.
• level angiver alvorligheden: informational, low, medium, high eller critical, og medium, når den mangler. ATT&CK-ID'er i tags (attack.t1110, attack.ta0006) udfylder fundets MITRE-felter.

Aggregeringer som | count() by principalIp > 5 afvises, når du gemmer: brug i stedet en korrelationsregel eller Group By Field og Match Count Threshold. logsource er kun informativ og indsnævrer intet: læg det filter i en selektion, f.eks. className: Authentication. En timeframe ignoreres, fordi regelens interval bestemmer dens vindue.

Korrelationsregler#

En Sigma-korrelation udløses af flere hændelser sammen i stedet for én. Indsæt den i Sigma Rule (YAML) sammen med de regler, den læser, som YAML-dokumenter adskilt af ---, eller navngiv regler, projektet allerede har, med deres Sigma-name eller -id. Rule Library har færdige, f.eks. mislykkede logins efterfulgt af et 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 værdien af felterne i group-by, f.eks. én adresse. Optællinger er rullende: et udbrud, som to kørsler deler, tælles stadig helt inden for sit timespan, som højst er 24 timer.
• new_value er Status200s egen type, da Sigma ikke har nogen korrelation for "set første gang": den sammenligner med op til 30 dages historik. value_sum, value_avg, value_percentile og value_median afvises, når du gemmer.
• Kolonnen Type i Detection Rules angiver hver regels slags, og formularen siger i én sætning, hvad reglen leder efter.

Evalueringsindstillinger#

Group By og Distinct Count tager de samme feltnavne som reglen. Med dem siger tærsklen "så mange, fra den samme ting, i én kørsel", uden en monitor ovenpå:

Hvornår en regel kører#

Status200 tjekker hvert minut for aktiverede regler, hvis interval er gået siden deres sidste kørsel. Hver kørsel læser de begivenheder, hvis begivenhedstidspunkt ligger mellem den forrige kørsel og for to minutter siden, og går så videre. De to minutter giver plads til begivenheder, der stadig er på vej, for eksempel en loglinje, der læses et minut efter, at den blev skrevet:

• Vinduerne ligger i forlængelse af hinanden og glider ikke. Med et interval på 10 minutter kan fejl kl. 09:58 og 10:01 lande i forskellige kørsler og tælles hver for sig, så hold en margin, når du vælger en tærskel.
• Efter et hul, f.eks. et worker-nedbrud eller en regel, der er slået til igen, dækker den næste kørsel hele hullet, op til de seneste 24 timer.
• En begivenhed, der ankommer mere end to minutter for sent, efter at en kørsel har dækket dens tidspunkt, gemmes og kan søges, men den regel læser den aldrig.
• Hver gruppe, der når tærsklen, bliver et Detection Finding, op til 10.000 pr. kørsel. Advarsler, hændelser og sager åbnes for de 100 med de højeste optællinger; resten deler én sag om reglen, og reglens Seneste fejl fortæller, hvor mange grupper der matchede.

Alvorlighed#

En regels level er alvorligheden af dens fund: informational, low, medium, high og critical bliver til Informational, Low, Medium, High og Critical. Dens advarsler og hændelser får en af dit projekts alvorligheder i denne rækkefølge:

1. Regelens Advarselsalvor (eller Hændelsesalvor), når den er angivet.
2. Din alvorlighed, der er opkaldt efter niveauet, f.eks. High, uanset store og små bogstaver.
3. Efter rang: regler med critical og high får din mest alvorlige alvorlighed, de andre din mindst alvorlige.

Advarsler og fund#

Hver gruppe, der udløses, åbner en advarsel med titlen [Detection] <rule name> — <group value>, eller [Detection] <rule name> for en regel uden Group By Field. Så længe den er åben, åbner flere match for den gruppe ikke en ny. En regel ser kun match og kan ikke se, at et angreb er stoppet, så dens advarsler forbliver åbne, indtil nogen løser dem.

Et Detection Finding er en sikkerhedsbegivenhed af klassen Detection Finding (OCSF-klasse 2004) fra produktet Status200 Detections, med regelens MITRE-tags, gruppeværdien først i observables og disse attributter:

Fund er almindelige begivenheder: søg efter dem under Begivenheder, og pivotér på dem i Korrelér. For at afprøve en ny regel i stilhed slår du alle handlinger undtagen fundet fra, indtil du stoler på den.

Monitorer for sikkerhedsbegivenheder#

En monitor for sikkerhedsbegivenheder tæller de begivenheder, der matcher dens filtre, over et glidende vindue og kører de sædvanlige monitorkriterier på optællingen: den ændrer monitorens status, åbner advarsler eller hændelser og tilkalder vagthavende. Opret en under Overvågninger → Opret monitor med Security Events som type; den vises der sammen med dine andre monitorer.

Dens formular viser Monitor events that include this text, Monitor Security Events for (time), Event Severity og Begivenhedsklasse. Filtrér efter telemetritjeneste og Filtrér efter attributter venter under Flere felter, hvis overskrift viser dem, en monitor bruger. Dens kriterier tjekker Security Event Count.

Skriv selve detektionen som en regel med dens tærskel. Brug en monitor, når du vil have et glidende vindue, en status, der retter sig selv igen, en statusside eller forskellige vagtpolitikker pr. kriterium.

Hold øje med dine detektioner#

Fund er begivenheder, så en monitor kan overvåge selve reglerne:

• Storme: en monitor på klassen Detection Finding, der tæller hvert fund. Tyve forskellige regler, der udløses inden for en time, er et signal, ingen enkelt regel kan se.
• Ændringer i hyppighed: filtrér på én regels status200.detection.rule_id. En regel, der udløses ugentligt og pludselig udløses halvtreds gange i timen, kræver en anden reaktion.
• Stilhed: fund, der falder til nul, når du normalt ser nogle få, betyder som regel, at en kilde er holdt op med at sende. Brug et kriterium, der tjekker for en optælling under et tal.

Handlingen Opret monitor i en regels række åbner en ny monitor, der allerede er sat op på denne måde: klassen Detection Finding, regelens ID (aldrig dens navn, som en omdøbning ville ændre) og den seneste time. En sådan monitor tæller fund, ét pr. gruppe pr. kørsel, ikke begivenhederne bag dem. For at kræve et antal begivenheder, før noget udløses, bruger du regelens Match Count Threshold.

Trusselsintelligens#

Threat Intel abonnerer på STIX/TAXII-feeds med kendte ondsindede IP-adresser, domæner, URL'er, e-mailadresser og filhashes. Begivenheder, der nævner en af dem, mærkes med threat.*-attributter, når de ankommer, som regler og monitorer kan filtrere på, og hvert minut matches nylige begivenheder mod feedsene, hvilket åbner advarsler og fund, ligesom en regel gør. Se Trusselsintelligens.

Opbevaring og fakturering#

Sikkerhedsbegivenheder faktureres pr. indtaget GB ligesom resten af din telemetri og opbevares i din telemetriopbevaringsperiode: projektets Standardopbevaring (dage) under Projektindstillinger → Telemetri og APM → Dataopbevaring eller en opbevaring, der er angivet på den telemetritjeneste, de hører til. Når en begivenheds opbevaring udløber, slettes den.

Fejlfinding#

Næste trin#