Taggat med: dataintrång

Så hanterar Er organisation en cyberincident

Så hanterar Er organisation en cyberincident

Jag blir kontaktad då och då av organisationer som behöver hjälp att hantera cyberincidenter. Som tur var så lämnar de flesta incidenter någon form av spår som gör det möjligt att i efterhand spåra och dra slutsatser från incidenten. Men med goda förberedelser så kan Er organisation bli bättre på att hantera incidenter.

Den första frågan du bör ställa dig är: Har Er organisation redan rutiner på plats vid en cyberincident? Om inte så börja med att efterfråga en redan nu eller upprätta en rutin.

Betänk även att de flesta incidenter uppdagas genom att en extern part kontaktar Er och informerar om en incident som drabbar Er. Därför är det bra att ha kontaktuppgifter tillgängliga till säkerhetsavdelningen såsom E-post: [email protected] eller en webbsida som upplyser om vem man ska kontakta.

Glöm inte att löpande dokumentera allt som händer och vid vilka tidpunkter. Upprätta även en incidentrapport som ni uppdaterar hela tiden.

Koordinera och informera

Vem är det som bör informeras om incidenten. Finns det en säkerhetschef eller IT-säkerhetschef? Bör VD och styrelse snabbt informeras samt press-avdelning om externa frågor börjar att inkomma från allmänheten eller journalister.

Följande bild kommer från NIST SP 800-61r2 och beskriver hur kommunikation kan ske till och från ett Incident Response Team:

Isolera och begränsa

Att snabbt isolera och begränsa incidenten är också en viktig faktor, men betänk även att om det är ett pågående intrång så kan personen eller personerna i fråga ändra sitt beteende om de upptäcker att de blivit bortkopplade eller upptäckta.

Ett exempel på hur en server eller klient kan isoleras är att helt enkelt att fysiskt koppla bort den från nätverket och låta den fortsätta köra.

Säkra bevis

Att snabbt se till att säkra bevis efter incidenten är viktigt. För desto längre tid som går desto mer bevis kan gå förlorade. Det kan röra sig om ram-minne som försvinner om en server eller klient stängs av eller logg-filer som roteras och raderas efter en viss tid.

Titta vilka brandväggsloggar ni har, E-postloggar och AD-loggar samt andra relevanta loggfiler. Säkra upp dumpar av RAM-minne, hårddiskkopior och annat.

Det kanske är så att ni även måste kontakta en extern driftpartner eller organisation för att erhålla loggfiler.

Utreda omfattningen

Om det är ett intrång så är det viktigt att utreda exakt vilka system som drabbats av intrånget. Vid en överbelastningsattack så är det bra att veta vilka system som attackeras. Och när det gäller informationsläckage så måste ni veta exakt vilka uppgifter som ni blivit av med när, samt hur.

Vilka legala skyldigheter har organisationen och regelverk är det som måste följas såsom GDPR? Där det är 72 timmar som ni har på Er att informera Datainspektionen om personuppgiftsincidenter.

Rensa upp och återställ

Först och främst rekommenderar jag alltid att installera om och börja om från början. Men det är sällan så lätt i en komplex IT-miljö där det finns hundratals servrar och kanske tusentals användare och klienter.

Återställning handlar oftast om att rensa upp innehåll i databaser, se över användare och patcha eventuella system om sårbara produkter utnyttjas.

Lär av incidenten

Att dra relevanta slutsatser och förbättra på sitt cyberförsvar är något som Er organisation ska göra efter och under en incident. En incident är sällan en enskild isolerad händelse och har det inte hänt innan så kommer det troligtvis att inträffa en incident.

Hur kan ni upptäcka attacker tidigare och förbättra på rutinerna för att återställa verksamheten och minska påverkan i den operativa verksamheten.

Betänk även att en incident kan dra ut på flera dagar, veckor eller månader. Därför är det viktigt att ni har en eller flera som kan rotera huvudansvaret för incidenten vilket bidrar till bättre uthållighet. Därav också det viktiga med att dokumentera allt, så det blir lättare att lämna över och följa upp.

Utbildning

Jag skulle nästan påstå att organisationer som övar, informerar samt utbildar sin personal löpande i att hantera incidenter kommer att bli bättre på att hantera dessa den dagen de uppstår.

Att alla i organisationen känner till hur de ska hantera och identifiera incidenter är av stor vikt. Och om ni känner att det finns brister i dagsläget så tveka inte att ta in hjälp, det finns många företag som hjälper till med alla steg jag har listat i detta blogginlägg.

Har ni inte rutiner på plats i dagsläget så ta en titt på NIST Special Publication 800-61 revision 2 som tar upp mycket av det jag skriver om i detta blogginlägg.

Inspelning av nätverkstrafik (trafikinspelning)

TrafikinspelningVi har tidigare belyst vikten av att spela in rå nätverkstrafik för att möjliggöra och underlätta eventuella undersökningar av dataintrång eller försök till detta. Detta har speciellt varit på tapeten efter offentliggörandet av sårbarheten vid namn Heartbleed.

Om trafikinspelning används så skulle det vara möjligt att till viss del se om ett TLS heartbeat-paket skickats.

Det kan även vara en fördel att kryptera de råa filerna så att en enskild individ ej kan nyttja nätverkstrafiken (dubbelhandsfattning). Denna metod kallas även ibland för FPC (Full Packet Capture).

Teknisk lösning för trafikinspelning

Det finns flera sätt att lösa detta rent tekniskt. Ett sätt är att använda sig av dumpcap som en ringbuffer där man kan ställa in att exempelvis nyttja X antal GB spritt över X antal filer.

Se framförallt till att det finns tillräckligt med utrymme på hårddisken. Med fördel bör även utrustningen för trafikinspelning placeras på ett sådant sätt att maximalt med trafik ses, exempelvis vid en perimeter i nätverket eller vid centrala noder.

För att spela in nätverkstrafik 7 dagar oavsett hur mycket hårddisk som nyttjas skriver man följande kommando:

$ sudo dumpcap -i en0 -b duration:3600 -b files:168 -w packets.cap

En mer rekommenderad variant är att nyttja maximalt med tillgängligt diskutrymme och göra enligt följande om vi har 11 GB ledigt diskutrymme på filsystemet /pcap

$ sudo dumpcap -i en0 -b filsize:1048576 -b files:10 -w /pcap/packets.cap

Se även till att paketdumparna ligger på ett eget filsystem för att förhindra att diskutrymme tas upp av något annat i operativsystemet.

Nätverkstappar

IPACU3_SMFör att erhålla möjligghet att spegla av nätverkstrafik så kan man välja ett antal olika lösningar. Ett populärt sätt är att använda sig av en såkallad nätverkstapp. Det finns många olika nätverkstappar i olika priskategorier.

Det man bör titta efter är en med hög driftsäkerhet såsom dubbla nätverksaggregat samt som fungerar även vid strömbortfall. Även är aggregering en önskvärd funktion för att få RX samt TX via en enda kabel.

Netoptics har ett stort utbud av nätverkstappar men är rätt dyra, vill man ha en lite billigare variant så säljer Direktronik EasyTap som kostar runt 3000 SEK.

Även så går det att nyttja en såkallad span-port mirroring på många av dagens switchar:

Span port mirroring

Vidare läsning

daemonlogger_full_smKolla även in OpenFPC som använder sig av daemonlogger. Daemonlogger är utvecklad av Marty Roesch som även är grundaren till Snort.

Även så har nu Google utvecklat en mjukvara vid namn Stenographer som sparar ner stora mängder datatrafik till disk: https://github.com/google/stenographer

Tre miljoner patientjournaler på vift?

takecareKarolinska universitetssjukhuset och Stockholms läns landsting upptäckte efter en krasch i patientjournalsystemet TakeCare att dataintrång hade genomförts mot systemet.

Tyvärr så fanns det enbart 3 månaders loggfiler att tillgå vilket försvårade arbetet för de tre konsultfirmorna som var inblandade i analysarbetet.

För en individ som blir av med sin journal så finns det inte så mycket som går att göra, det är inte direkt som när ett lösenord är på vift där det finns möjlighet att byta lösenord. Det enda som kanske är värre är om någon stjäl din DNA-information.

Din patientjournal kan du aldrig byta ut. Enbart spärra i förhand men det har visats sig att få väljer att spärra sina journaler och i just detta fall så hade det nog ändå ej spelat någon roll.

DN skriver även:

Slutrapporten är ännu inte klar. Hittills har landstinget bara fått en teknisk delredovisning. Den slår enligt Nyström fast att inget intrång har skett.

Men frågan är ju, stödjer patientjournalsystemet TakeCare kryptering? Troligtvis inte då detta framgår av en tidigare granskning genomförd av landstingsrevisorerna:

Trots detta uppfyller journalsystemet inte till alla delar patientdatalagens krav. Det gäller bl.a. krav på kryptering och
stark autentisering (kontroll av uppgiven identitet). Källa

Och redan 2008 så uppdagade Marucs Jerräng på IDG att journaler skickas okrypterade:

Patientjournaler med känslig information skickas utan kryptering mellan olika sjukhus i Stockholms läns landsting. Uppgifter ur miljoner journaler riskerar att hamna i fel händer. Bristen har varit känd länge utan att ha åtgärdats.

Källor: IDG, DN