Säkerhetsärenden och playbooks (SOAR)

Security Events gör det som dina detektionsregler, hotunderrättelser och anslutna säkerhetsprodukter hittar till ärenden: ett ärende för varje sak som är värd att titta närmare på, med alla detektioner om samma användare, värd eller adress samlade i det. Analytiker arbetar med ärendena i en kö, och playbooks reagerar på dem, av sig själva eller med ett klick.

Så fungerar det#

Öppna Produkter → Security Events → Säkerhetsärenden → Öppna ärenden för kön. Tilldelade mig, Ej tilldelad, Stängda ärenden och Alla ärenden är egna sidor bredvid, och var och en listar de ärenden som namnet säger.

Innan du börjar#

Ärenden och playbooks följer de tre Security-rollerna. Project Owner och Project Admin kan göra allt.

Var och en av dessa behörigheter kan också ges för sig, från att skapa ett ärende till att godkänna en playbooks steg; se Behörighetsreferens.

Var ärenden kommer ifrån#

Alla källor är påslagna som standard. En anslutning öppnar ärenden för Hög och högre om du inte väljer en annan nivå; larmen under den nivån importeras ändå som händelser.

Så grupperas detektioner#

En detektion handlar om en entitet: värdet som dess regel grupperar efter, till exempel IP-adressen för en brute force-regel, eller indikatorn som en träff i hotunderrättelserna nämner. En detektion utan entitet står för sig själv.

• När ett öppet ärende redan handlar om den entiteten läggs detektionen till i det. Ärendets entiteter och ATT&CK-mappning växer, och dess prioritet höjs till detektionens, aldrig nedåt.
• När inget öppet ärende gör det öppnas ett nytt ärende, uppkallat efter detektionen, med detektionens prioritet.
• En detektion som löser ut igen räknas upp på sin rad i stället för att lägga till en ny.

Ett ärendes prioritet kommer från detektionens allvarlighetsgrad:

Arbeta med ett ärende#

Ett ärende går igenom fyra statusar. Det kan hoppa över en, till exempel när ett falsklarm stängs direkt från New, och det kan öppnas igen.

Ärendets sida har allt som behövs för att arbeta med det:

• Överst: Assign to Me, Run Playbook, Deklarera incident och Close Case, statusstegen, och prioriteten i menyn bredvid dem.
• Status200 AI: vad Status200 AI fick ut av ärendet, den prioritet och playbook som den föreslår, och bevisen bakom. Se Status200 AI i säkerhet.
• Detections: det som löste ut och öppnade ärendet eller lades till i det, hur ofta, och den senaste händelsen som träffade.
• Entiteter: användarna, värdarna och adresserna som ärendet handlar om, med deras aktivitet i alla dina säkerhetshändelser under de senaste 7 dagarna. Var och en öppnas i Korrelera.
• MITRE ATT&CK: taktikerna och teknikerna som dess detektioner mappas till, var och en länkad till sin sida på attack.mitre.org.
• Playbook-körningar: vad varje playbook gjorde i ärendet, steg för steg, och stegen som väntar på godkännande.
• Anteckningar och Tidslinje: vad teamet skrev, och allt som hände, med vem som gjorde det.

För att arbeta med flera ärenden samtidigt markerar du dem i kön och använder Assign to Me, Change Status eller Change Priority.

Stäng ett ärende#

Close Case ber om en bedömning och en valfri avslutande anteckning:

Bedömningarna räknas på översikten. En regel vars ärenden gång på gång stängs som False Positive är en regel som behöver finjusteras.

Ett ärende som öppnats från Google SecOps-larm stänger dem också i Google SecOps, med utlåtandet och avslutningsanteckningen, när dess anslutning har Stäng varningar när deras ärende stängs påslaget: se Google SecOps.

Deklarera en incident#

Deklarera incident öppnar en Status200-incident för ärendet, med den allvarlighetsgrad du väljer, och länkar dem åt båda hållen: incidentens beskrivning nämner ärendet, och ärendets rubrik länkar till incidenten. Därifrån tar jour, statussidor och postmortem över. Det kräver en roll som både kan arbeta med ärenden och skapa incidenter.

Aviseringar#

Status200 berättar för personer om tre saker som händer i ett ärende. Ingen behöver ställa in något: ett projekt som bara har klickat på Slå på rekommenderat får veta om sina ärenden med High och Critical via e-post och push.

• Bara personer som kan se ärendet får veta om det: Project Owner, Project Admin och rollerna Security Admin, Security Member och Security Viewer. Den som har en roll som är begränsad till vissa etiketter får bara veta om ärenden med de etiketterna.
• Ingen får veta om det den själv har gjort: den som öppnar ett ärende manuellt, tilldelar det eller startar en körning aviseras inte om det.
• Varje person får bara veta om ett ärende en gång. Ett ärende som öppnas med Medium och senare stiger till Critical når dem som valde High eller Critical när det stiger, men inte igen dem som valde Medium, som fick veta om det när det öppnades.
• Testattacken från Skicka en testattack öppnar ett ärende som inte aviserar någon.
• Ett ärende med Critical och ett steg som väntar på godkännande skickas direkt och hålls aldrig kvar i en e-postsammanfattning.
• Ärendets Tidslinje visar vem som fick veta, och när.

Välj vad du får veta#

Var och en väljer själv, under Användarinställningar → Aviseringsinställningar → Säkerhet: kanalerna för varje avisering (e-post, SMS, samtal, push, Telegram, Slack, Microsoft Teams eller webhook) och, under Nytt säkerhetsärende, från vilken prioritet de aviseras:

WhatsApp-meddelanden skickas inte för säkerhetsärenden. En push-avisering öppnar Status200-appen, och dess länk öppnar ärendet i webbläsaren.

Posta i kanaler i Slack och Microsoft Teams#

För att posta i en kanal lägger du till en regel under Produkter → Security Events → Arbetsyta → Slack (eller Microsoft Teams). När inget av dem är anslutet är avsnittets enda post Anslut Slack eller Teams. En regel anger vilka kanaler den postar i (och, i Microsoft Teams, vilka chattar) och, om du vill, vilka ärenden den gäller:

Var och en av de tre aviseringarna postas i kanalerna för varje regel som ärendet matchar just då. En regel där Prioritet för säkerhetsärende innehåller någon av Kritisk och High postar ärenden med High och Critical när de öppnas, och ett ärende med Medium när det stiger till High. Ett säkerhetsärende får aldrig en egen kanal.

Playbooks#

En playbook är en lista med steg som körs på ett ärende. Skapa en under Produkter → Security Events → Playbooks, från en mall eller tom, och lägg till dess steg på dess sida.

När en playbook körs#

Alla aktiverade playbooks kan också köras manuellt, med Run Playbook på ett ärende. En playbook som körs av sig själv kan begränsas:

• For Cases At Least: bara ärenden med den här prioriteten eller högre.
• Only For Detections From: bara när detektionen bakom ärendet kom från den här källan.
• Only For These Detection Rules: bara när den kom från någon av de här reglerna.

En inaktiverad playbook körs varken av sig själv eller manuellt.

Steg#

En playbook har högst 25 steg. De körs i ordning, vart och ett när det föregående är klart. Varje steg har också de här inställningarna:

• Needs Approval: stoppar körningen före steget tills någon godkänner det i ärendet. För de fyra stegen som stänger ute någon är den alltid påslagen, om inte en Security Admin slår av den.
• Only If Threat Intel Matched: hoppar över steget om inte ett tidigare steg Check entities against threat intel i körningen hittade en känd indikator.
• Carry On If It Fails: kör nästa steg även om det här misslyckas. Är den avstängd stoppar ett misslyckat steg körningen.

Begränsning#

Begränsningsstegen agerar via en anslutning för säkerhetshändelser till produkten, och den behöver mer än läsbehörighet:

Ett begränsningssteg agerar bara på de användare eller värdar som ärendet handlar om, aldrig på alla som det nämner:

• Värdet som en detektion i ärendet grupperas efter, till exempel kontot som en regel för omöjliga resor grupperar efter, eller värden som ett larm från en ansluten produkt nämner.
• En användare eller värd i ärendet som dina hotunderrättelser känner till som en indikator.

Ett ärende som grupperas efter en adress, till exempel en brute force-attack mot ditt VPN, handlar om ingetdera: dess begränsningssteg hoppas över, och kontot som attacken prövade och gatewayen som den träffade lämnas i fred. Ett steg agerar på högst 10 användare eller värdar. Det letar upp var och en i produkten efter namn och skriver i körningen vad det gjorde med var och en: klart, redan klart, hittades inte, nekades eller skyddad.

Skyddade entiteter#

Protected Entities, under Playbooks i menyn, listar de användare och värdar som ingen playbook begränsar, till exempel konton för nödåtkomst, domänkontrollanter och VPN-gatewayer. Ett värde matchar oavsett skiftläge, och * står för en valfri följd av tecken: svc-* skyddar alla tjänstkonton. Ett steg rapporterar en skyddad användare eller värd som skyddad och lämnar den i fred. Listan sköts av användare med rollen Security Admin.

Godkännande#

De fyra stegen som stänger ute någon väntar på godkännande. Bara en Security Admin kan slå av Needs Approval för ett av dem, och Status200 registrerar vem som gjorde det. Godkännandet listar användarna eller värdarna som steget skulle agera på under Act On, alla förbockade: avmarkera dem som steget ska lämna i fred. Skyddade finns inte med bland alternativen. Den som startade en körning kan inte godkänna dess steg: det gör någon annan, men den som startade körningen kan fortfarande avvisa steget.

Ångra#

Ångringsstegen agerar på de användare eller värdar som ärendet handlar om, precis som stegen de ångrar. När körningen har stannat har en begränsad användare eller värd också en egen knapp på sitt steg: Unsuspend, Lift Containment eller Frigör. En avslutad Okta-session kan inte ångras. Varje ångring sparas på ärendets tidslinje och i projektets granskningslogg.

Meddelanden#

En anteckning, ett mejl, ett Slack-inlägg och ett Teams-inlägg kan använda ärendets värden:

Ett mejl eller ett inlägg utan eget meddelande skickar en sammanfattning av ärendet.

Körningar och godkännanden#

Varje körning listas, steg för steg, i sitt ärende och under Produkter → Security Events → Playbooks → Playbook-körningar:

Ett steg som väntar på godkännande visar Approve och Reject på körningen, med en valfri kommentar. Ett godkännande låter körningen fortsätta från det steget; ett avvisande avslutar den. Beslutet, vem som fattade det och kommentaren sparas på steget, på ärendets tidslinje och i projektets granskningslogg. Väntar på godkännande, under Playbooks i menyn, listar körningarna som väntar på ett beslut och räknar dem; Playbook-körningar listar varje körning.

En körning vars worker slutar höra av sig, till exempel efter en omstart, tas upp igen: en köad körning läggs i kö på nytt efter 2 minuter, och en körning som inte har hörts av på 30 minuter markeras som misslyckad.

Översikten#

Produkter → Security Events → Översikt är där produkten öppnas:

• De öppna ärenden som är tilldelade dig, de öppna ärenden som ingen har tagit sig an, och playbook-stegen som väntar på godkännande; varje tal öppnar sidan som listar dem.
• Genomsnittlig tid till kvittering, Genomsnittlig tid till begränsning och Genomsnittlig tid till stängning, över ärendena som öppnats under de senaste 30 dagarna: från att ett ärende öppnas till att någon tar sig an det (en person tilldelas, eller det flyttas ut ur New), till Contained och till Closed. Ett ärende som fortfarande väntar räknas inte in i något medelvärde.
• Ärendena som öppnats varje dag i 30 dagar, efter prioritet, och detektionerna som skapats varje dag i 14 dagar, efter källa.
• De öppna ärendena efter prioritet och efter status, bedömningarna från de senaste 30 dagarna, ATT&CK-taktikerna bakom ärendena, detektionerna som löste ut oftast, och entiteterna som nämns i flest fynd.

Ovanför visar en remsa hur säkerhet är uppsatt: dess källor, detektioner, ärenden och playbooks, var och en med sina siffror. Ett projekt som ännu inte har satt upp det ser Slå på rekommenderat och Skicka en testattack där; se Kom igång med säkerhet. När inget behöver någon säger sidan Allt är lugnt, och diagrammen visas så snart det finns något att visa.

Hitta hot#

• Entiteter rangordnar användarna, värdarna, adresserna och hasharna som dina fynd nämner oftast, under det senaste dygnet, den senaste veckan eller månaden, och slår upp vilket värde som helst i 30 dagars händelser.
• Rule Library har färdiga detektionsregler för hot mot identiteter, slutpunkter, moln, nätverk, webb och Kubernetes. Var och en är en Sigma-regel skriven för fälten som varje ansluten källa normaliseras till. Lägg till regel skapar den som en egen detektionsregel, påslagen och med ärenden i stället för larm; ändra den under Detection Rules som vilken annan regel som helst. Reglerna markerade Rekommenderade hittar hot i data som Status200 redan har, och en knapp lägger till dem du inte har än.
• ATT&CK Coverage ritar MITRE ATT&CK-matrisen med teknikerna som dina aktiverade regler täcker upplysta, och ramar in de som en regel i biblioteket skulle täcka.

Automatisera#

• Arbetsflöden: ett ärende eller en anteckning kan starta ett arbetsflöde när det skapas, uppdateras eller tas bort. Ett steg Run a workflow startar ett arbetsflöde vars utlösare är en webhook.
• API: ärenden, anteckningar, detektioner, playbooks, körningar och skyddade entiteter har samma REST API som resten av Status200, under /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run och /security-protected-entity. Se API-referens.
• AI-agenter: MCP-servern har verktyg för ärenden, anteckningar, detektioner och playbooks. Se MCP-server.

Felsökning#

Nästa steg#