Hantering av datasäkerhetsincidenter

Inom områdena datorsäkerhet och informationsteknologi innefattar hantering av incidenter för datorsäkerhet övervakning och upptäckt av säkerhetshändelser på en dator eller ett datornätverk och utförandet av korrekta svar på dessa händelser. Datasäkerhetsincidenthantering är en specialiserad form av incidenthantering , vars primära syfte är att utveckla ett välförstått och förutsägbart svar på skadliga händelser och datorintrång.

Incidenthantering kräver en process och ett insatsteam som följer denna process. Denna definition av hantering av datorsäkerhetsincidenter följer standarderna och definitionerna som beskrivs i National Incident Management System (NIMS). Incidentsamordnaren hanterar insatserna vid en akut säkerhetsincident . Vid en naturkatastrof eller annan händelse som kräver insatser från räddningstjänsten skulle incidentkoordinatorn fungera som en länk till räddningstjänstens incidentchef.

Översikt

Hantering av datasäkerhetsincidenter är en administrativ funktion för att hantera och skydda datortillgångar, nätverk och informationssystem. Dessa system fortsätter att bli mer kritiska för den personliga och ekonomiska välfärden i vårt samhälle. Organisationer (grupper i den offentliga och privata sektorn, föreningar och företag) måste förstå sitt ansvar för allmänhetens bästa och för deras medlemmars och intressenters välfärd. Detta ansvar sträcker sig till att ha ett ledningsprogram för "vad man ska göra, när saker går fel." Incidenthantering är ett program som definierar och implementerar en process som en organisation kan anta för att främja sin egen välfärd och allmänhetens säkerhet.

Komponenter av en incident

evenemang

En händelse är en observerbar förändring av det normala beteendet hos ett system, miljö, process, arbetsflöde eller person (komponenter). Det finns tre grundläggande typer av evenemang:

1. Normal – en normal händelse påverkar inte kritiska komponenter eller kräver ändringskontroller innan en lösning implementeras. Normala evenemang kräver inte deltagande av högre personal eller ledningsmeddelande om evenemanget.
2. Eskalering – en eskalerad händelse påverkar kritiska produktionssystem eller kräver implementering av en lösning som måste följa en förändringskontrollprocess. Eskalerade evenemang kräver deltagande av ledande personal och intressentmeddelanden om evenemanget.
3. Nödsituation – en nödsituation är en händelse som kan
   1. påverka människors hälsa eller säkerhet
   2. bryter mot primära kontroller av kritiska system
   3. väsentligt påverka komponentprestanda eller på grund av påverkan på komponentsystem förhindra aktiviteter som skyddar eller kan påverka individers hälsa eller säkerhet
   4. anses vara en nödsituation som en policyfråga eller genom tillkännagivande av den tillgängliga incidentsamordnaren

Datasäkerhets- och informationsteknikpersonal måste hantera nödsituationer enligt väldefinierad åtgärdsplan för datasäkerhetsincidenter.

Incident

En incident är en händelse som kan hänföras till en mänsklig grundorsak. Denna distinktion är särskilt viktig när händelsen är resultatet av uppsåt att göra skada. En viktig anmärkning: alla incidenter är händelser men många händelser är inte incidenter. Ett system- eller programfel på grund av ålder eller defekt kan vara en nödsituation, men ett slumpmässigt fel eller fel är inte en incident.

Incident respons team

Säkerhetsincidentsamordnaren hanterar responsprocessen och ansvarar för att sammansätta teamet . Samordnaren kommer att se till att teamet inkluderar alla individer som är nödvändiga för att korrekt bedöma incidenten och fatta beslut angående den rätta handlingen. Incidentteamet träffas regelbundet för att granska statusrapporter och för att godkänna specifika åtgärder. Teamet bör använda en förtilldelad fysisk och virtuell mötesplats.

Incidentutredning

Utredningen syftar till att fastställa omständigheterna kring händelsen. Varje incident kommer att motivera eller kräva en utredning. Utredningsresurser som kriminaltekniska verktyg, smutsiga nätverk, karantännätverk och samråd med brottsbekämpande myndigheter kan dock vara användbara för en effektiv och snabb lösning av en nödsituation.

Bearbeta

Inledande incidenthanteringsprocess

Författare: Michael Berman (tanjstaffl)

1. Anställd, leverantör, kund, partner, enhet eller sensor rapporterar händelse till Help Desk .
2. Innan biljetten skapas kan helpdesk filtrera händelsen som en falsk positiv. Annars skapar helpdesk-systemet en biljett som fångar händelsen, händelsekällan, den initiala händelsens svårighetsgrad och händelseprioriteten.
   1. Biljettsystemet skapar ett unikt ID för evenemanget. IT-personal måste använda biljetten för att fånga e-post, snabbmeddelanden och annan informell kommunikation.
   2. Efterföljande aktiviteter som ändringskontroll, incidenthanteringsrapporter och efterlevnadsrapporter måste referera till biljettnumret.
   3. I de fall evenemangsinformationen är "Begränsad åtkomst" måste biljetten referera till relevanta dokument i det säkra dokumenthanteringssystemet.
3. Den första nivåsvararen fångar ytterligare händelsedata och utför en preliminär analys. I många organisationer är mängden evenemang betydande i förhållande till personalen. Som ett resultat kan automatisering tillämpas, vanligtvis i form av ett SOAR-verktyg (security orchestration, automation and response), integrerat med ett intelligens-API. SOAR-verktyget automatiserar utredningen via en arbetsbok för automatisering av arbetsflöden. Cyberintelligens API gör att spelboken kan automatisera forskning relaterad till biljetten (sök potentiell webbadress för nätfiske, misstänkt hash, etc.). First Responder avgör händelsens kriticitet. På den här nivån är det antingen en normal eller en eskaleringshändelse.
   1. Normala händelser påverkar inte kritiska produktionssystem eller kräver ändringskontroller innan en lösning implementeras.
   2. Händelser som påverkar kritiska produktionssystem eller kräver förändringskontroller måste eskaleras.
   3. Organisationsledningen kan begära en omedelbar eskalering utan granskning på första nivån – 2:a nivån kommer att skapa biljett.
4. Händelsen är redo att lösas. Resursen matar in lösningen och problemkategorin i ärendet och skickar in ärendet för stängning.
5. Biljettägaren (anställd, säljare, kund eller partner) får beslutet. De avgör att problemet är löst till deras belåtenhet eller eskalerar biljetten.
6. Upptrappningsrapporten uppdateras för att visa denna händelse och biljetten tilldelas en resurs på andra nivå för att undersöka och svara på händelsen.
7. Second Tier-resursen utför ytterligare analys och omvärderar ärendets kriticitet. Vid behov ansvarar Second Tier-resursen för att implementera en förändringskontroll och meddela IT-ledningen om händelsen.
8. Nödutryckning:
   1. Händelser kan följa eskaleringskedjan tills det fastställs att en nödåtgärd är nödvändig.
   2. Organisationsledning på högsta nivå kan bestämma att en nödåtgärd är nödvändig och åberopa denna process direkt.

Detalj för nödsituationer

Författare: Michael Berman (tanjstaffl)

1. Nödåtgärder initieras genom eskalering av en säkerhetshändelse eller genom en direkt förklaring från CIO eller annan verkställande organisationspersonal. CIO kan tilldela incidentsamordnaren, men som standard kommer samordnaren att vara den högsta säkerhetspersonalen som finns tillgänglig vid tidpunkten för incidenten.
2. Incidentsamordnaren sätter ihop incidentresponsteamet. Teamet träffas med hjälp av ett fördefinierat konferensmötesutrymme. En av (CIO, CSO eller Director IT) måste närvara vid varje incidentteammöte.
3. Mötesprotokollet visar status, åtgärder och resolution(er) för incidenten. Incidentsamordnaren rapporterar kostnaden, exponeringen och fortlöpande affärsrisk för incidenten. Incidentresponsteamet bestämmer nästa tillvägagångssätt.
4. Låsa ner och reparera – Utför de åtgärder som är nödvändiga för att förhindra ytterligare skador på organisationen, reparera påverkade system och utför ändringar för att förhindra att en återkomst inträffar.
5. Falskt positivt – Incidentteamet fastställer att detta problem inte motiverade en nödåtgärd. Teamet ger en skriftlig rapport till den högsta ledningen och frågan hanteras antingen som en normal incident eller så är den avslutad.
6. Övervaka och fånga – Utför en grundlig utredning med fortsatt övervakning för att upptäcka och fånga gärningsmannen. Denna process måste omfatta meddelande till följande seniora och professionella personal:
   1. VD och CFO
   2. Företagsadvokat och PR
7. Granska och analysera loggdata för att fastställa incidentens art och omfattning. Detta steg bör inkludera användning av virus, spionprogram, rootkit och andra detekteringsverktyg för att fastställa nödvändig begränsning och reparation.
8. Reparera system, eliminera attackvektor(er) och minska exploateringsbara sårbarheter.
9. Testrapporten dokumenterar valideringen av reparationsprocessen .
   1. Testa system för att säkerställa efterlevnad av policy och riskreducering.
   2. Utför ytterligare reparationer för att lösa alla aktuella sårbarheter.
10. Undersök incidenten för att fastställa källan till attacken och fånga gärningsmannen. Detta kommer att kräva användning av kriminaltekniska verktyg, logganalys, rent labb och smutsiga labbmiljöer och eventuell kommunikation med brottsbekämpande myndigheter eller andra externa enheter.
11. "Utredningsstatusrapporten" som fångar all aktuell information om incidenten. Incidentresponsteamet använder denna information för att bestämma nästa åtgärd. (Se Ref 2 och Ref 3)

Definitioner

First Responder/Första nivå granskar

den första personen som är på plats eller tar emot meddelanden om en händelse, organisationer bör ge utbildning till den första räddningspersonalen för att känna igen och reagera korrekt på nödsituationer.

Help Desk Ticket (Control)

ett elektroniskt dokument som fångas in i en databas och ärendespårning/lösningssystem.

Biljettägarens

person som rapporterar händelsen, huvudägaren av tillgångarna som är associerade med evenemanget eller ägaren enligt lag eller jurisdiktion.

Eskaleringsrapport (kontroll)

First Responders dokumentation för biljetteskalering, svararen skriver in denna information i biljetten eller WIKI-loggen för evenemanget. Biljetten refererar till WIKI-loggen för evenemanget.

Second Tier

Senior tekniska resurser tilldelade för att lösa en eskalerad händelse.

Incidentsamordnare

som utsetts av organisationens högsta ledning för att sammansätta incidentresponsteamet, hantera och dokumentera respons på incidenten.

Undersökningsstatusrapport (Kontroll)

dokumentation av aktuella undersökningsresultat, samordnaren kan dokumentera detta material i biljetten, WIKI eller en ingenjörs journal.

Mötesprotokoll (kontroll)

dokumentation av incidentteammötet, protokollet dokumenterar deltagarna, händelsens aktuella karaktär och de rekommenderade åtgärderna. Samordnaren kan dokumentera detta material i biljetten, WIKI eller en ingenjörsjournal.

Lock-down Change Styr

en process som beställs som en lösning på incidenten. Denna process följer samma behörighets- och svarskrav som en nödändringskontroll.

Testrapport (kontroll)

Den här rapporten validerar att IT-personal har utfört alla nödvändiga och tillgängliga reparationer av system innan de sattes tillbaka online.

War Room

en säker miljö för granskning av konfidentiellt material och utredning av en säkerhetsincident.

Rapportera till ledning (kontroll)

incidentkoordinatorn ansvarar för att upprätta en ledningsrapport . Samordnaren kan dokumentera detta material i biljetten, WIKI eller en ingenjörsjournal

Incident Response Steg

• Detektering – En incident kan upptäckas av en sensor, en nätverksanalytiker eller en användare som rapporterar något ovanligt med sin PC.

• Inneslutning – I händelse av skadlig nätverkstrafik eller ett datavirus bör Incident Response Manager stoppa trafiken genom att ta datorn från nätverket.

• Rengör – Kör en virussökning för att ta bort viruset eller rensa datorn och återbilda maskinen.

• Omvänd teknik – Använd datorkriminaltekniska verktyg för att förstå varför den skadliga trafiken inträffade i första hand. När händelsen är helt förstått gör planer för att minska din framtida risk.

Se även

• Beredskapsteam för datorer
• Proaktivt cyberförsvar
• USA:s nationella incidenthanteringssystem

Vidare läsning

• Handbok för datasäkerhetsincidentresponsteam (CSIRT) http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm