Säkerhetshändelser (SIEM)

Status200 lagrar säkerhetshändelser bredvid dina loggar, spår och metriker, och ger alla samma form, OCSF (Open Cybersecurity Schema Framework), oavsett vilket format de kom i. Skicka händelser från vilken källa som helst, sök i dem och hitta de viktiga med Sigma-detektionsregler, hotunderrättelser och monitorer. Det de hittar blir ärenden att arbeta med, och playbooks reagerar på dem.

Så fungerar det#

Öppna Produkter → Security Events, under Observerbarhet. Dess meny har ett avsnitt för varje del av säkerheten, och en egen sida för varje sak i den:

Detections, AI och Connections, som sätts upp en gång, förblir hopfällda tills du öppnar dem. Ny inom säkerhet? Kom igång med säkerhet sätter upp det med två klick.

Innan du börjar#

Säkerhetsdata kan bara läsas av rollerna Project Owner och Project Admin och av de tre Security-rollerna; andra roller ser ingenting i Security Events. Se Roller.

Skicka säkerhetshändelser#

1. Skapa en ingestion-nyckel#

   Öppna Projektinställningar → Telemetri och APM → Intagningsnycklar och klicka på Skapa ingestion-nyckel. Säkerhetshändelser använder samma nycklar som resten av din telemetri.

2. Skicka dina händelser#

   Skicka JSON till /security-events/v1/ingest med nyckeln 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" } ] }'

   Slutpunkten svarar 200 när händelserna har lagts i kö. En händelse som skickas utan tid, som dessa, placeras vid den tidpunkt då den kommer in.

3. Hitta dem under Händelser#

   Öppna Produkter → Security Events → Händelser. Händelserna visas inom några sekunder, med allvarlighetsgrad, klass, användare, värd och IP-adresser ifyllda.

Format#

Ange formatet med ?format=, med huvudet x-oneuptime-security-event-format eller med ett fält "format" på översta nivån. Utelämnar du det avgörs varje händelses format för sig, så en enda webhook kan blanda detektioner med råa händelser.

• Kroppen kan vara en händelse, en array av händelser eller { "events": [...] }.
• Huvudet x-status200-service-name anger telemetritjänsten som händelserna hör till. Utan det hör de till tjänsten som är uppkallad efter den första händelsens produkt eller leverantör, eller till Security Events.
• Ingenting kastas för att det inte gick att mappa: varje fält från källan hamnar i händelsens attribut.

Fält i generisk JSON#

En generisk händelse läses utifrån vanliga fältnamn:

Ett ord för allvarlighetsgrad blir en OCSF-nivå: info läses som Informational, warning som Low, error som Medium, alert som Critical och emergency som Fatal.

Vidarebefordra med Fluent Bit#

För att skicka säkerhetsloggar som du redan samlar in, till exempel auditd, syslog eller Falco, lägger du till en http-utdata 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

Sidan Installationsguide, under Connections, har de här kodsnuttarna med din egen värd och nyckel ifyllda.

Hitta säkerhetshändelser i dina loggar#

Kortet Dina loggar, högst upp på Connections, gör loggarna du redan skickar till Status200 till en källa. Med Hitta säkerhetshändelser i dina loggar påslaget läses projektets nya loggar varje minut, och varje SSH-inloggning, sudo-kommando, Kubernetes-granskningspost, AWS CloudTrail-ändring och webbattack i dem lagras som en säkerhetshändelse. Se Kom igång med säkerhet för vad varje typ täcker.

Anslut en säkerhetsprodukt#

Connections hämtar data från en säkerhetsprodukt åt dig och importerar dess nya poster som säkerhetshändelser. En anslutning innehåller produktens inställningar och en krypterad autentiseringsuppgift; en worker hämtar från den med intervallet du anger och hoppar över poster som den redan har importerat.

• Produktens egna larm på eller över Open Cases From (Hög och högre om du inte väljer en annan nivå, eller Aldrig) öppnar ärenden, grupperade efter användaren, värden eller adressen som de handlar om.
• En anslutning läser poster efter tiden då produkten skapade dem, inte efter tiden för aktiviteten de beskriver. En SIEM-regel som körs varje timme skapar detektioner långt efter händelserna den träffade, och de importeras ändå.
• Den första hämtningen tittar 24 timmar bakåt, så en ny anslutning visar nya poster direkt.
• Testa anslutningen, i anslutningens rad, kontrollerar åtkomsten till produkten och att Status200s egna workers körs, och importerar ingenting. Run now hämtar direkt.

Vad en händelse innehåller#

Varje händelse lagras med typade fält och källans nyttolast:

Utforska säkerhetshändelser#

Händelser är en telemetriutforskare som utforskarna för loggar och spår: ett diagram över fönstrets händelser efter allvarlighetsgrad, en sidopanel med facetter, listan och en panel med varje fält och attribut i händelsen du öppnar. Fönstret, filtren och sökningen finns alla i URL:en, så en filtrerad vy kan delas och överlever en omladdning.

Sök#

Sökfältet talar samma språk som de andra telemetriutforskarna (se Söksyntax):

Ett fält är antingen ett kort namn (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) eller fältets eget namn, till exempel severityName eller principalHost. Alla andra namn läses som ett källattribut. observable:<value> hittar varje händelse som nämner ett värde, oavsett på vilken sida av aktiviteten det fanns.

Facetter#

Sidopanelen räknar fönstrets händelser efter Källa, Allvarlighetsgrad, Händelseklass, Category, Aktivitet, Status, Leverantör, Produkt, Detection Rule, Källanvändare, Källvärd, Process och Överordnad process. Klicka på ett värde för att bara behålla dess händelser, eller på minustecknet bredvid för att utesluta dem. Klicka igen för att ångra. Diagrammet och varje räkning beskriver exakt händelserna i listan.

Korrelera#

Korrelera ritar händelserna runt en värd, en användare eller en IP-adress: deras händelseklasser runt det du sökte efter, markerade med sin värsta allvarlighetsgrad, och de andra värdena från samma händelser på den yttre ringen. Klicka på en klass för att lista dess händelser, eller på ett värde för att korrelera på det härnäst. Varje observable i en händelses panel under Händelser öppnar Korrelera på den.

Detektionsregler#

En detektionsregel är en Sigma-regel, ett öppet YAML-format för att beskriva misstänkt aktivitet, som Status200 kör enligt ett schema mot dina händelser. När den träffar öppnar den ett ärende eller lägger träffen i ett som redan är öppet, öppnar ett larm, eventuellt en incident, och skriver ett Detection Finding tillbaka bland händelserna. Rule Library har färdiga regler att utgå från.

Skapa en regel#

En första regel, som träffar misslyckade inloggningar utanför 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

Vad en regel kan uttrycka#

Status200 kör den booleska kärnan i Sigma:

• Urval är fältmappningar (varje fält måste träffa; en lista med värden träffar vilket som helst av dem) eller nyckelordslistor, som träffar var som helst i meddelandet.
• Villkor kombinerar urval med and, or, not och parenteser, eller med 1 of selection_*, all of selection_*, any of them och all of them.
• Fältmodifierare: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists och windash. Text jämförs utan hänsyn till versaler och gemener, om du inte lägger till cased.
• Ett fält är ett typat fält (principalUser), en vanlig Sigma-stavning av ett (CommandLine, src_ip, Hostname) eller vilken attributnyckel som helst, stavad som i händelsen (threat.matched).
• Image och CommandLine läser den process som händelsen handlar om, vid en processtart den som startade (processPath, processCommandLine), och ParentImage och ParentCommandLine den process som startade den (parentProcessPath, parentProcessCommandLine). principalProcess är den process som agerade, vilket vid en start är den överordnade.
• level anger allvarlighetsgraden: informational, low, medium, high eller critical, och medium när den saknas. ATT&CK-ID:n i tags (attack.t1110, attack.ta0006) fyller i fyndets MITRE-fält.

Aggregeringar som | count() by principalIp > 5 avvisas när du sparar: använd en korrelationsregel, eller Group By Field och Match Count Threshold, i stället. logsource är bara informativ och begränsar ingenting: lägg det filtret i ett urval, till exempel className: Authentication. En timeframe ignoreras, eftersom regelns intervall bestämmer dess fönster.

Korrelationsregler#

En Sigma-korrelation utlöses av flera händelser tillsammans i stället för en. Klistra in den i Sigma Rule (YAML) tillsammans med reglerna den läser, som YAML-dokument åtskilda av ---, eller namnge regler som projektet redan har med deras Sigma-name eller -id. Rule Library har färdiga, till exempel misslyckade inloggningar följda av en lyckad.

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 grupp är värdet av fälten i group-by, till exempel en adress. Räkningar är rullande: en skur som två körningar delar räknas ändå hel inom sitt timespan, som är högst 24 timmar.
• new_value är Status200s egen typ, eftersom Sigma saknar en korrelation för "först sedd": den jämför med upp till 30 dagars historik. value_sum, value_avg, value_percentile och value_median avvisas när du sparar.
• Kolumnen Typ i Detection Rules visar varje regels slag, och formuläret säger i en mening vad regeln letar efter.

Utvärderingsinställningar#

Group By och Distinct Count tar samma fältnamn som regeln. Med dem säger tröskeln ”så här många, från samma sak, i en körning”, utan någon monitor ovanpå:

När en regel körs#

Status200 kontrollerar varje minut om det finns aktiverade regler vars intervall har gått sedan deras senaste körning. Varje körning läser händelserna vars händelsetid infaller mellan den föregående körningen och för två minuter sedan, och går sedan vidare. De två minuterna ger utrymme åt händelser som fortfarande är på väg, till exempel en loggrad som läses en minut efter att den skrevs:

• Fönstren ligger efter varandra och glider inte. Med ett intervall på 10 minuter kan misslyckanden kl. 09:58 och 10:01 hamna i olika körningar och räknas var för sig, så lämna marginal när du väljer en tröskel.
• Efter ett uppehåll, till exempel ett worker-avbrott eller en regel som slagits på igen, täcker nästa körning hela uppehållet, upp till de senaste 24 timmarna.
• En händelse som kommer mer än två minuter för sent, efter att en körning redan har täckt dess tid, lagras och är sökbar, men den regeln läser den aldrig.
• Varje grupp som når tröskeln blir ett Detection Finding, upp till 10 000 per körning. Larm, incidenter och ärenden öppnas för de 100 med högst räkning; resten delar ett ärende om regeln, och regelns Senaste fel säger hur många grupper som träffade.

Allvarlighetsgrad#

En regels level är allvarlighetsgraden för dess fynd: informational, low, medium, high och critical blir Informational, Low, Medium, High och Critical. Dess larm och incidenter får en av projektets allvarlighetsgrader, i den här ordningen:

1. Regelns Varningsallvar (eller Incidentallvar), när den är angiven.
2. Din allvarlighetsgrad som är uppkallad efter nivån, till exempel High, oavsett versaler och gemener.
3. Efter rang: regler med critical och high får din allvarligaste allvarlighetsgrad, de andra din minst allvarliga.

Larm och fynd#

Varje grupp som löser ut öppnar ett larm med titeln [Detection] <rule name> — <group value>, eller [Detection] <rule name> för en regel utan Group By Field. Så länge det är öppet öppnar fler träffar för den gruppen inget nytt. En regel ser bara träffar och kan inte avgöra att en attack har upphört, så dess larm förblir öppna tills någon löser dem.

Ett Detection Finding är en säkerhetshändelse av klassen Detection Finding (OCSF-klass 2004) från produkten Status200 Detections, med regelns MITRE-taggar, gruppvärdet först i observables och de här attributen:

Fynd är vanliga händelser: sök efter dem under Händelser och pivotera på dem i Korrelera. För att prova en ny regel i det tysta stänger du av alla åtgärder utom fyndet tills du litar på den.

Monitorer för säkerhetshändelser#

En monitor för säkerhetshändelser räknar händelserna som träffar dess filter över ett glidande fönster och kör de vanliga monitorkriterierna på räkningen: den ändrar monitorns status, öppnar larm eller incidenter och larmar jourhavande. Skapa en under Övervakare → Skapa monitor, med Security Events som typ; den listas där med dina andra monitorer.

Dess formulär visar Monitor events that include this text, Monitor Security Events for (time), Event Severity och Händelseklass. Filtrera efter telemetritjänst och Filtrera efter attribut väntar under Fler fält, vars rubrik visar vilka en monitor använder. Dess kriterier kontrollerar Security Event Count.

Skriv själva detektionen som en regel, med dess tröskel. Använd en monitor när du vill ha ett glidande fönster, en status som återhämtar sig av sig själv, en statussida eller olika jourpolicyer per kriterium.

Håll koll på dina detektioner#

Fynd är händelser, så en monitor kan bevaka själva reglerna:

• Stormar: en monitor på klassen Detection Finding, som räknar varje fynd. Tjugo olika regler som löser ut inom en timme är en signal som ingen enskild regel kan se.
• Förändringar i takt: filtrera på en regels status200.detection.rule_id. En regel som löser ut varje vecka och plötsligt löser ut femtio gånger i timmen kräver en annan respons.
• Tystnad: fynd som sjunker till noll, när du normalt ser några stycken, betyder oftast att en källa har slutat skicka. Använd ett kriterium som kontrollerar om räkningen understiger ett tal.

Åtgärden Skapa monitor i en regels rad öppnar en ny monitor som redan är konfigurerad på det här sättet: klassen Detection Finding, regelns ID (aldrig dess namn, som ett namnbyte skulle ändra) och den senaste timmen. En sådan monitor räknar fynd, ett per grupp och körning, inte händelserna bakom dem. För att kräva ett antal händelser innan något löser ut använder du regelns Match Count Threshold.

Hotunderrättelser#

Threat Intel prenumererar på STIX/TAXII-flöden med kända skadliga IP-adresser, domäner, URL:er, e-postadresser och filhashar. Händelser som nämner en av dem märks med threat.*-attribut när de kommer in, som regler och monitorer kan filtrera på, och varje minut matchas nya händelser mot flödena, vilket öppnar larm och fynd som en regel gör. Se Hotunderrättelser.

Lagring och fakturering#

Säkerhetshändelser faktureras per GB som tas in, som resten av din telemetri, och lagras enligt din lagringstid för telemetri: projektets Standardlagring (dagar), under Projektinställningar → Telemetri och APM → Datalagring, eller en lagringstid som angetts på telemetritjänsten de hör till. När en händelses lagringstid löper ut tas den bort.

Felsökning#

Nästa steg#