Sikkerhetssaker og playbooks (SOAR)

Security Events gjør det deteksjonsreglene, trusseletterretningen og de tilkoblede sikkerhetsproduktene dine finner, om til saker: én sak for hver ting som er verdt å undersøke, med alle deteksjoner om samme bruker, vert eller adresse samlet i den. Analytikere behandler sakene i en kø, og playbooks reagerer på dem, av seg selv eller med et klikk.

Slik fungerer det#

Åpne Produkter → Security Events → Sikkerhetssaker → Åpne saker for køen. Tildelt meg, Ikke tildelt, Lukkede saker og Alle saker er egne sider ved siden av, og hver viser sakene navnet sier.

Før du begynner#

Saker og playbooks følger de tre Security-rollene. Project Owner og Project Admin kan gjøre alt.

Hver av disse rettighetene kan også gis for seg, fra å opprette en sak til å godkjenne stegene i en playbook; se Tillatelsesreferanse.

Hvor saker kommer fra#

Alle kilder er på som standard. En tilkobling åpner saker for Høy og høyere med mindre du velger et annet nivå; varslene under det nivået importeres fortsatt som hendelser.

Slik grupperes deteksjoner#

En deteksjon gjelder en entitet: verdien regelen grupperer etter, for eksempel IP-adressen i en brute force-regel, eller indikatoren som et treff fra trusseletterretning nevner. En deteksjon uten entitet står alene.

• Når en åpen sak allerede gjelder den entiteten, legges deteksjonen til i den. Sakens entiteter og ATT&CK-tilordning vokser, og prioriteten heves til deteksjonens, men senkes aldri.
• Når ingen åpen sak gjør det, åpnes en ny sak, oppkalt etter deteksjonen, med deteksjonens prioritet.
• En deteksjon som slår til igjen, teller opp på sin egen rad i stedet for å legge til en ny.

Prioriteten til en sak kommer fra deteksjonens alvorlighetsgrad:

Behandle en sak#

En sak går gjennom fire statuser. Den kan hoppe over en, for eksempel en false positive som lukkes rett fra Ny, og den kan åpnes på nytt.

Siden til saken har alt du trenger for å behandle den:

• Øverst: Assign to Me, Run Playbook, Erklær hendelse og Close Case, statusstegene, og prioriteten under menyen ved siden av dem.
• Status200 AI: hva Status200 AI fikk ut av saken, prioriteten og playbooken den foreslår, og bevisene bak. Se Status200 AI i sikkerhet.
• Detections: det som slo til og åpnet saken eller ble lagt til i den, hvor ofte, og den siste hendelsen som traff.
• Entiteter: brukerne, vertene og adressene saken gjelder, med aktiviteten deres på tvers av alle sikkerhetshendelsene dine de siste 7 dagene. Hver av dem åpnes i Korreler.
• MITRE ATT&CK: taktikkene og teknikkene deteksjonene i saken er tilordnet, hver med en lenke til sin side på attack.mitre.org.
• Playbook-kjøringer: hva hver playbook gjorde på saken, steg for steg, og stegene som venter på godkjenning.
• Notater og Tidslinje: hva teamet skrev, og alt som skjedde, med hvem som gjorde det.

For å behandle flere saker samtidig merker du dem i køen og bruker Assign to Me, Change Status eller Change Priority.

Lukk en sak#

Close Case ber om en konklusjon og et valgfritt avslutningsnotat:

Konklusjonene telles på oversikten. En regel der sakene stadig lukkes som False Positive, er en regel som bør justeres.

En sak som er åpnet fra Google SecOps-varsler, lukker dem også i Google SecOps, med konklusjonen og avslutningsnotatet, når tilkoblingen har Lukk varsler når saken deres lukkes slått på: se Google SecOps.

Erklær en hendelse#

Erklær hendelse åpner en Status200-hendelse (incident) for saken, med alvorlighetsgraden du velger, og kobler de to sammen begge veier: beskrivelsen av hendelsen nevner saken, og toppen av saken lenker til hendelsen. Vaktordningen, statussider og postmortem tar over derfra. Det krever en rolle som både kan behandle saker og opprette hendelser (incidents).

Varslinger#

Status200 gir folk beskjed om tre ting på en sak. Ingen trenger å sette opp noe: et prosjekt som bare har klikket på Slå på anbefalt, får høre om sakene sine med prioritet High og Kritisk via e-post og push.

• Bare personer som kan se saken, får beskjed om den: Project Owners, Project Admins og rollene Security Admin, Security Member og Security Viewer. En rolle som er begrenset til noen etiketter, får bare beskjed om sakene med de etikettene.
• Ingen får beskjed om det de selv gjorde: den som åpner en sak manuelt, tildeler den eller starter en kjøring, blir ikke varslet om det.
• Hver person får høre om en sak én gang. En sak som åpnes på Medium og senere stiger til Kritisk, når ved stigningen fram til dem som valgte High eller Kritisk, og ikke på nytt til dem som valgte Medium, for de fikk høre om den da den ble åpnet.
• Testangrepet fra Send et testangrep åpner en sak som ikke varsler noen.
• En sak med Kritisk og et steg som venter på godkjenning, sendes med en gang og holdes aldri tilbake i en e-postoppsummering.
• Sakens Tidslinje viser hvem som fikk beskjed, og når.

Velg hva du får beskjed om#

Hver person velger selv, under Brukerinnstillinger → Varselinnstillinger → Sikkerhet: kanalene for hver varsling (e-post, SMS, anrop, push, Telegram, Slack, Microsoft Teams eller webhook), og under Ny sikkerhetssak prioriteten som varsler dem:

Det sendes ikke WhatsApp-meldinger for sikkerhetssaker. Et push-varsel åpner Status200-appen, og lenken i det åpner saken i nettleseren.

Legg ut i Slack- og Microsoft Teams-kanaler#

For å legge ut i en kanal legger du til en regel under Produkter → Security Events → Arbeidsområde → Slack (eller Microsoft Teams). Er ingen av dem koblet til, er seksjonens eneste oppføring Koble til Slack eller Teams. En regel angir kanalene den legger ut i (og i Microsoft Teams chattene) og, om du vil, sakene den gjelder for:

De tre varslingene legges hver ut i kanalene til hver regel saken treffer i det øyeblikket. En regel der Prioritet for sikkerhetssak inneholder en av Kritisk og High, legger ut saker med High og Kritisk når de åpnes, og en sak med Medium når den stiger til High. En sikkerhetssak får aldri en egen kanal.

Playbooks#

En playbook er en liste med steg som kjører på en sak. Opprett en under Produkter → Security Events → Playbooks, fra en mal eller fra bunnen av, og legg til stegene på siden dens.

Når en playbook kjører#

Enhver aktivert playbook kan også kjøres manuelt, med Run Playbook på en sak. En playbook som kjører av seg selv, kan snevres inn:

• For Cases At Least: bare saker med denne prioriteten eller høyere.
• Only For Detections From: bare når deteksjonen bak saken kom fra denne kilden.
• Only For These Detection Rules: bare når den kom fra en av disse reglene.

En deaktivert playbook kjører verken av seg selv eller manuelt.

Steg#

En playbook har høyst 25 steg. De kjører i rekkefølge, hvert steg når det forrige er ferdig. Hvert steg kan også:

• Needs Approval: stoppe kjøringen før steget til noen godkjenner det på saken. De fire stegene som stenger noen ute, stopper alltid kjøringen, med mindre en Security Admin slår det av.
• Only If Threat Intel Matched: hoppe over steget med mindre et tidligere steg Check entities against threat intel i kjøringen fant en kjent indikator.
• Carry On If It Fails: kjøre neste steg selv om dette feiler. Er det av, stopper et mislykket steg kjøringen.

Inndemming#

Contain-stegene handler gjennom en tilkobling for sikkerhetshendelser til produktet, og den trenger mer enn lesetilgang:

Et Contain-steg handler bare på brukerne eller vertene saken gjelder, aldri på alle som den nevner:

• Verdien en deteksjon i saken er gruppert etter, for eksempel kontoen en regel for umulige reiser grupperer etter, eller verten som et varsel fra et tilkoblet produkt nevner.
• En bruker eller vert i saken som trusseletterretningen din kjenner som en indikator.

En sak som er gruppert etter en adresse, for eksempel et brute force-angrep mot VPN-en din, gjelder ingen av delene: Contain-stegene i den hoppes over, og den forsøkte kontoen og den rammede gatewayen får være i fred. Et steg handler på høyst 10 brukere eller verter. Det finner hver av dem i produktet etter navn, og skriver på kjøringen hva det gjorde med hver enkelt: utført, allerede utført, ikke funnet, avvist eller beskyttet.

Beskyttede entiteter#

Protected Entities, under Playbooks i menyen, viser brukerne og vertene som ingen playbook demmer inn, for eksempel nødtilgangskontoer, domenekontrollere og VPN-gatewayer. En verdi treffer uten forskjell på store og små bokstaver, og * står for en hvilken som helst rekke tegn: svc-* beskytter alle tjenestekontoer. Et steg melder en beskyttet bruker eller vert som beskyttet og lar den være i fred. Security Admins vedlikeholder listen.

Godkjenning#

De fire stegene som stenger noen ute, venter på godkjenning. Bare en Security Admin kan slå av Needs Approval for ett av dem, og Status200 registrerer hvem som gjorde det. Godkjenningen viser under Act On brukerne eller vertene steget ville handlet på, alle avkrysset: fjern krysset for dem det skal la være i fred. Beskyttede brukere og verter tilbys ikke. Den som startet en kjøring, kan ikke godkjenne stegene i den: det gjør noen andre, men vedkommende kan fortsatt avvise det.

Angre#

Angrestegene handler på brukerne eller vertene saken gjelder, akkurat som stegene de angrer. Når kjøringen har stoppet, har en inndemmet bruker eller vert også en egen knapp på steget sitt: Unsuspend, Lift Containment eller Frigi. En avsluttet Okta-økt kan ikke angres. Alt som angres, lagres på tidslinjen til saken og i revisjonsloggen til prosjektet.

Meldinger#

Et notat, en e-post, et Slack-innlegg og et Teams-innlegg kan bruke verdiene til saken:

En e-post eller et innlegg uten egen melding sender en oppsummering av saken.

Kjøringer og godkjenninger#

Hver kjøring vises på saken sin og under Produkter → Security Events → Playbooks → Playbook-kjøringer, steg for steg:

Et steg som venter på godkjenning, viser Approve og Reject på kjøringen, med en valgfri kommentar. Å godkjenne fører kjøringen videre fra det steget; å avvise avslutter den. Beslutningen, hvem som tok den, og kommentaren deres lagres på steget, på tidslinjen til saken og i revisjonsloggen til prosjektet. Venter på godkjenning, under Playbooks i menyen, viser kjøringene som venter på en beslutning, og teller dem; Playbook-kjøringer viser hver kjøring.

En kjøring som slutter å høre fra workeren sin, for eksempel etter en omstart, plukkes opp igjen: en kjøring i kø settes i kø på nytt etter 2 minutter, og en kjøring som ikke har sagt noe på 30 minutter, markeres som mislykket.

Oversikten#

Produkter → Security Events → Oversikt er der produktet åpner:

• De åpne sakene som er tildelt deg, de åpne sakene ingen har tatt, og playbook-stegene som venter på godkjenning; hvert tall åpner siden som viser dem.
• Gjennomsnittlig tid til kvittering, Gjennomsnittlig tid til begrensning og Gjennomsnittlig tid til lukking, over sakene som er åpnet de siste 30 dagene: fra en sak åpnes til noen tar den (tildeler en person eller flytter den ut av Ny), til Contained og til Lukket. En sak som fortsatt venter, telles ikke med i et gjennomsnitt.
• Sakene som er åpnet hver dag i 30 dager, etter prioritet, og deteksjonene som er utløst hver dag i 14 dager, etter kilde.
• De åpne sakene etter prioritet og etter status, konklusjonene fra de siste 30 dagene, ATT&CK-taktikkene bak sakene, deteksjonene som slo til oftest, og entitetene som flest funn nevner.

Over dem viser en stripe hvordan sikkerhet er satt opp: kildene, deteksjonene, sakene og playbookene, hver med tallene sine. Et prosjekt som ennå ikke har satt det opp, ser Slå på anbefalt og Send et testangrep der; se Kom i gang med sikkerhet. Når ingenting trenger noen, sier siden Alt er rolig, og diagrammene vises så snart det er noe å vise.

Finn trusler#

• Entiteter rangerer brukerne, vertene, adressene og hashene som funnene dine nevner oftest, over det siste døgnet, den siste uken eller måneden, og slår opp hvilken som helst verdi på tvers av 30 dager med hendelser.
• Rule Library har ferdige deteksjonsregler for trusler mot identitet, endepunkter, sky, nettverk, web og Kubernetes. Hver av dem er en Sigma-regel skrevet for feltene som alle tilkoblede kilder normaliseres til. Legg til regel oppretter den som din egen deteksjonsregel, slått på og med saker i stedet for varsler; endre den under Detection Rules som alle andre. Reglene merket Anbefalt finner trusler i data Status200 allerede har, og én knapp legger til dem du ikke har ennå.
• ATT&CK Coverage tegner MITRE ATT&CK-matrisen, uthever teknikkene de aktiverte reglene dine dekker, og rammer inn teknikkene en regel fra biblioteket ville dekket.

Automatiser#

• Arbeidsflyter: en sak eller et notat kan starte en arbeidsflyt når den opprettes, oppdateres eller slettes. Et steg Run a workflow starter en arbeidsflyt som har en webhook som utløser.
• API: saker, notater, deteksjoner, playbooks, kjøringer og beskyttede entiteter har det samme REST-API-et som resten av Status200, under /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run og /security-protected-entity. Se API-referanse.
• AI-agenter: MCP-serveren har verktøy for saker, notater, deteksjoner og playbooks. Se MCP-server.

Feilsøking#

Neste steg#