Till innehåll på sidan

Exempel från verkligheten

Här har vi samlat exempel på inträffade allvarliga it-incidenter - bland annat handhavandefel, angrepp och informationsförlust. Till exemplen har vi tagit fram rekommendationer till myndigheter för att förebygga dem.

Ladda ner rapporten i sin helhet

Innehållet på den här sidan är ett utdrag av årsrapporten, som du kan ta del av i sin helhet genom att ladda ner den som pdf-fil.

Årsrapport it-incidentrapportering 2019

MSB har utifrån myndigheternas inrapportering tagit fram några lärande exempel på allvarliga it-incidenter. Till varje exempel finns råd för hur myndigheter kan förebygga och hantera respektive it-incident. Dessa exempel kan användas som komplement till de föreskrifter och vägledningar som MSB i övrigt har tagit fram för att stötta myndigheterna i deras systematiska och riskbaserade informations- och cybersäkerhetsarbete.

De vanligast förekommande kategorierna i rapporteringen är handhavandefel och angrepp, som tillsammans utgör ungefär 45 procent av de inrapporterade incidenterna.

Exempel på vanliga IT-incidenter

  • Angrepp - anställd fick obehörig tillgång till personuppgifter

    En användare i ett hr-system på en myndighet upptäckte att hen hade tillgång till information som hen inte skulle ha tillgång till och hade på så sätt kunnat hämta ut ytterligare uppgifter för vilka behörighet saknats. Informationen tillgängliggjordes genom en sql-injektion (structured query language). Användaren uppmärksammade detta för sin chef, och blev påtalad det olämpliga i att utnyttja detta. Ytterligare slagningar skedde och därför beslutade myndigheten att polisanmäla incidenten. Funktionaliteten som möjliggjorde ett utnyttjande stängdes av då buggen blev känd, och rättades i en ny version av hr-systemet några dagar senare.

    Rekommendation

    Generellt bör man uppdatera sårbarheter i produkter så snart som det är möjligt.

    När det gäller att förhindra sql-injektioner så är den första åtgärden att kontrollera vilka applikationer (om några alls) är sårbara. Ett sätt är att utföra penetrationstester på applikationerna i sin it-miljö, egna ”attacker”, för att se om det går att komma åt de egna systemen eller information i dem. Tänk på att applikationer bör testas med hjälp av kända ramverk (exempelvis OWASP  och PTES ).

    Indatavalidering är också en effektiv metod för att säkerställa att bara rätt data tas emot.

    När det gäller att åtgärda sårbarheter för sql-attacker kommer man även långt med så kallade prepared statements, en funktion som används för att utföra samma eller liknande databasuppdrag upprepade gånger med hög effektivitet. Vid sql-injektioner används ofta en förberedd mall där vissa konstanta värden ersätts under varje exekvering.

    I det beskrivna fallet finns även problematik med arbetsmiljön, medarbetaren uppmärksammar chefen på problemet men åtgärden dröjer. Se till att eftersträva en transparent arbetsplatskultur så att medarbetare känner sig trygga i vetskapen att problem som lyfts upp snabbt blir åtgärdade.

  • Angrepp - skräppost passerade e-postfiltret

    Myndigheten fick in skräppost som passerade e-postfiltret. I meddelandet uppmanades användare att byta lösenord genom att följa en länk. Totalt lurades 103 användare att lämna ut sina inloggningsuppgifter.

    En extern aktör utnyttjade sedan e-postkonton hos myndigheten i syfte att skicka skräppost. Kontouppgifterna missbrukades inte på andra sätt, enligt den drabbade myndigheten. Genom loggar kunde man spåra vilka användare som anslutit mot den externa webbservern, och på så sätt identifiera kapade konton. Dessa konton inaktiverades och deras respektive lösenord byttes ut.

    Så fort som myndigheten blev medveten om nätfisket blockerades tillgången till den externa sajten. Vidare loggades alla försök att få tillgång till sajten och dessa konton inaktiverades. Myndigheten övervakade också sitt skräppostfilter för att se om några försök att skicka ut skräppost hade gjorts. Efter tre dagar bedömdes det akuta skedet vara över.

    Omfattningen av incidenten var att cirka 200 000

    skräppostmeddelanden skickades ut från myndighetens e-postserver. En effekt blev att myndigheten fick problem att skicka e-post under två timmar då den blev svartlistad av ett flertal domäner. Den hade också återkommande problem med fördröjning av e-postleverans på grund av den tidigare svartlistningen.

    I incidentrapporten framgår även att myndigheten planerade genomföra ett antal utbildningsinsatser för att minska risken att liknande händelser sker igen. Den planerade även att byta sitt e-postfilter samt införa säkerhetshöjande åtgärder på sina e-postservrar.

    Rekommendation

    Myndigheten har vidtagit ett antal korrekta åtgärder för att förhindra att liknande incidenter igen. Förutom informationsinsatser för att utbilda personalen om kända nätfiskemetoder och hur känslig information bör delas (eller inte) så rekommenderas en översyn av diverse skyddslösningar och kontrollsystem för att säkerställa att tillräckligt skydd är installerat i alla led i it-miljön.

  • Handhavandefel - felaktigt konfigurerat ftp-konto

    Vid en kontroll av myndighetens ftp-konton (file transfer protocol), som del av ett arbete med att avveckla dessa, konstaterades att ett konto hade satts upp på sådant vis att en fil låg tillgänglig för alla som hade åtkomst till kontot. Lösningen hade varit uppsatt på detta sätt sedan flera år tillbaka. De som hade åtkomst till kontot var ett hundratal organisationer som rapporterar in känsliga uppgifter, bland annat om sina anställda. Flera fel hade begåtts i fallet, bland annat hade interna krav på behörighetsstyrning inte efterlevts då flera organisationer hade tillgång till samma ftp-konto. Vidare hade uppgifter kunnat lämnas via en okrypterad förbindelse. Det fanns också en risk att enskilda filer potentiellt funnits tillgängliga för andra organisationer då de hade tillgång till samma konto.

    De flesta organisationer som rapporterar in uppgifter har maskin-till-maskin-överlämnande av filer men de som hade tillgång till kontot hade således möjligheten att logga in manuellt. Därför fanns risken att olika organisationer kunde se varandras information som längst en timme för varje lämnad fil, innan den flyttades. Det fanns även en risk att någon med tillgång till kontot skulle ha kunnat ladda ner information på regelbunden basis. Den kortsiktiga lösningen på problemet var att stänga kontot helt och säkerställa att uppgiftslämnare använde det säkrare protokollet sftp (secure file transfer protocol), som garanterar bättre behörighetshantering och krypterad överföring.

    Rekommendation

    Det är olämpligt att flera olika användare har tillgång till samma ftp-konto för överföring och hantering av filer, särskilt sådana med känsligt innehåll. Om flera använder samma konto försvåras möjligheten att spåra vem som gjort vad, och vem som tagit del av informationen som är publicerad där. Dessutom saknar ftp-protokollet tillräckliga krypteringsfunktioner för hantering av känsliga personuppgifter. Istället bör det säkrare alternativet sftp användas, och i fallet ovan fanns detta de facto tillgängligt att använda. Det bör också införa metoder för verifiering av sin it-miljö, så att det finns en person som är ytterst ansvarig för att säkerställa att kravspecifikationen för den levererade tjänsten uppfylls.

  • Handhavandefel - nätverksloop via switch skapade totalstopp

    En supporttekniker vid myndigheten skapade en nätverksloop via en switch. Detta resulterade i att samma programkod kördes om och om igen, med totalstopp i nätverket som följd.

    Initialt gjordes försök till felsökning genom att utföra omstarter av en central switch. När detta inte avhjälpte felet så upptäcktes väldigt många paketförluster på en specifik port. Efter ytterligare felsökningar så kunde felet härledas till en specifik port på en lokal switch. Tekniker stängde av porten för vidare felsökning.

    I den aktuella porten satt en lokal omanagerad nätverksswitch som hade en nätverkskabel kopplad mellan två portar, vilket skapade en nätverksloop. Omfattningen påverkade all nätverkstrafik på myndigheten. Vidare felsökning visade att det tilläggsprotokoll som skulle ha kunnat förhindra nätverksloopen (spanning tree) inte var korrekt konfigurerat. Detta hanterades av tekniker och implementerades överlag i myndighetens it-miljö.

    Rekommendation

    Det är enkelt att av misstag koppla ihop två portar och oavsiktligt skapa den här typen av problem. Det finns tekniska lösningar som kan upptäcka om så skett, exempelvis loopskydd som sänder protokollpaket från portarna där skyddet aktiverats. Om det upptäcker att protokollet tar emot samma paket i en port som sänder, stängs porten som protokollet skickades från ned. Se även till att endast behörig personal kan göra förändringar i nätverk, nätverksstruktur- och topologi.

  • Informationsläckage vid systemuppdatering

    I samband med en systemuppdatering som genomfördes inför årsskiftet 2018–2019 inträffade en incident där uppgifter röjdes under den givna perioden. Detta uppdagades och rapporterades först under hösten 2019. Incidenten visade att ett antal personers information oavsiktligt ändrades i samband med den tidigare systemhändelsen och risken var att dessa känsliga uppgifter kunde ha röjts.

    Vid den första analysen bedömde myndigheten att incidenten omfattade cirka 160 personer med skyddade personuppgifter, och att detta var kopplat till den specifika systemhändelsen.

    Myndigheten kunde inte hitta några indikationer på att de skyddade uppgifterna hade utnyttjats av obehöriga internt i systemmiljöerna eller vid kontakt med myndigheten.

    Rekommendation

    Det är viktigt att verifiera att förändringar i it-miljön får det resultat som man förväntat sig. I det här fallet hade lång tid förflutit mellan händelsen och upptäckten av den. Ett sätt att minska risken för att något liknande inträffar är att se över verifieringsrutiner och även se till att det finns någon som är ytterst ansvarig för att förändringarna sker korrekt och fullständigt.

  • Informationsläckage vid borttagning av lagringsytor

    En händelse av informationsförlust inträffade på en myndighet då en anställd hade skickat in en begäran om att tre lagringsytor skulle tas bort, vilket en tekniker utförde. Den anställde var dock inte medveten om att både backup- och arkivdata ingick i samma lagringsyta.

    Två månader efter verkställandet återkom den anställde och ville läsa arkivdata från dessa lagringsytor, vilket inte var möjligt då all information som var sparad i dessa ytor var raderad. Myndigheten hade fått information om att det bara var backupdata som skulle försvinna om man raderade en lagringsyta, men så var inte fallet. Det har alltid varit så att både backup- och arkivdata tas bort vid radering.

    Konsekvensen av denna incident var att relevant data gick förlorad då den inte gick att återställa efter så pass lång tid.

    Rekommendation

    Man bör se till att inte ha sin backup och sitt arkiv på samma ställe. Gör skillnad på produktionsdata (det vill säga levande dokument som används under arbetets gång) och den information som ska lagras under en längre tid eller permanent. Det är också lämpligt att ha en extra backup på annan fysisk plats. Om den enda backupen ligger aktivt i nätet finns risken att den krypteras vid en eventuell ransomware-attack.

    När man gör en förändring i it-miljön bör man även se över sina verifieringsrutiner, så att de genomförda ändringarna överensstämmer med de uppställda förväntningarna. Om det finns avvikelser så är sannolikheten att kunna återställa informationen större ju närmre händelsen i tid man är, så det är viktigt att dessa upptäcks skyndsamt.

  • Operativt stöd från CERT-SE

    CERT-SE fick information från en forskare i ett annat land att det fanns sårbarheter i ett underliggande bibliotek i en samhällskritisk tjänst en myndighet levererar. Efter att CERT-SE varit i kontakt med myndighetens incidenthanterare så inleddes interna undersökningar, där även myndighetens säkerhetsfunktion var delaktig. Säkerhetsansvarig undersökte den potentiella sårbarheten och försökte då att bekräfta informationen som CERT-SE hade delgett. Kontakt med övriga relevanta funktioner inom myndigheten hölls löpande under dagen.

    Ungefär tio timmar efter att informationen kom in var en ny version av tjänsten klar att läggas ut i produktion. All testning av tjänsten hade gått bra och beslut fattades att publicera den, vilket också skedde efter ytterligare några minuter.

    Sårbarheten skulle ha kunna medfört en incident där känsliga personuppgifter spreds till obehöriga. Myndigheten bedömde dock risken att så faktiskt skett var låg, eftersom sannolikheten att någon skulle hitta luckan var liten.

    Efter incidenten reviderade myndigheten sina processer och införde rutiner för kontinuerlig uppdatering av stödtjänster och bibliotek för att på så vis avhjälpa risken för sårbarheter.

    Rekommendation

    Myndigheten har gjort allt rätt i detta fall, den har agerat skyndsamt och åtgärdat den potentiellt kritiska incidenten. Förutom de processer som myndigheten själv sett över så är det viktigt att granska aktiviteten i samtliga loggar i it-miljön (systemloggar, trafikloggar etc.) om en sårbarhet upptäckts. Om det finns risk att inloggningsuppgifter så som användarnamn och lösenord har läckt, så bör man också vidta åtgärder för att försäkra sig om att samma uppgifter inte använts även på andra tjänster.

  • Oönskad eller oplanerad störning i kritisk infrastruktur

    En eftermiddag drabbades myndigheten av ett avbrott hos sin mobiltelefonioperatör. Myndighetens möjligheter att kommunicera med omvärlden med mobiltelefon var då mycket begränsade. Samtal tappades, bröts, var helt tysta eller gick inte fram. Detta medförde stor påverkan på flera verksamhetsområden inom myndigheten, med effekter för såväl anställda som allmänheten.

    Samma kväll klarskrevs incidenten av mobiloperatören men problemen återkom efterföljande morgon, och pågick då fram till eftermiddagen. Incidenten klarskrevs igen på eftermiddagen dag två, med undantag för kapacitetsproblem till och från mobiloperatören. Detta medförde i sin tur problem med övervakningslösningar som gick på mobiloperatörens nät. Detta problem åtgärdades under kvällen dag två. Följande dag genomförde mobiloperatören åtgärdsarbeten och uppgraderade då diverse utrustning. 

    Totalt drabbades myndigheten under en och en halv dag. Under denna tidsperiod kompletterades mobiltelefonitjänsten med fasta telefoner samt mobiltelefoner med annan operatör.

    Rekommendation

    För verksamheter som levererar samhällskritiska tjänster är det viktigt att upphandla redundanta leverantörer, så att man snabbt kan ställa om till en annan aktör om problem med tjänsteleverans eller liknande uppstår.

    I kritiska lägen går det också att använda sig av SGSI,  Swedish government secure intranet, ett nätverk för datakommunikation mellan myndigheter, som är skilt från internet.

    Det är även viktigt att upphandla stränga serviceavtal om vilka krav som ställs på tjänsten. Förutom krav på kostnader, driftsäkerhet, antal fel och hastighet bör incidenthantering vara ett krav. Kraven bör anges så att de blir mätbara.

  • Störning i driftsmiljön vid blixtnedslag i dator

    Ett blixtnedslag slog ut en dator, vilket innebar allvarliga störningar i en myndighets samhällskritiska verksamhet. Påverkan pågick i nästan ett dygn. Ingen reservdator av den typ som behövs för verksamheten fanns på plats utan en tekniker var tvungen att ta med sig en dator från annan ort och konfigurera den.

    På grund av bristande rutiner fördröjdes lösningen av incidenten. Enligt dokumentation skulle en färdigkonfigurerad reservdator finnas på plats, men på grund av bristande rutiner var så inte fallet.  Incidenten fick stora konsekvenser på leverans av samhällskritisk tjänst.

    Rekommendation

    Vädret är svårt att rå på men interna rutiner kan man däremot ha bättre kontroll över. När det gäller samhällskritisk verksamhet är det av yttersta vikt att ha reservutrustning nära till hands, och redo för användning, för att minimera samhällsstörningen i tid och omfång. Rutinerna och dokumentationen kring detta bör ses över så att liknande händelser inte inträffar i ett kritiskt läge.

 

Senast granskad: 1 april 2020

Kontakta

När du skickar in formuläret kommer vi att behandla dina personuppgifter för att utföra den uppgift som formuläret avser. Tänk på att det du skickar in kan bli en allmän handling.

Till toppen av sidan