IT-säkerhet enligt HPS

I början av december i fjol släppte Myndigheten för samhällsskydd och beredskap (MSB) sitt "Ramverk för informationssäkerhet" (ramverket verkar inte ha något annat officiellt namn). Det rapporterades på flera håll från intresserade. Från pressmeddelandet den 15 december:

Nu ska det bli lättare för kommuner, myndigheter och företag att arbeta systematiskt med informationssäkerhet i enlighet med internationella standarder.

Detta tack vare ett ramverk för informationssäkerhet som MSB har tagit fram tillsammans med Försvarsmakten, Försvarets materielverk (FMV), Försvarets radioanstalt (FRA), Post- och telestyrelsen (PTS) och Rikspolisstyrelsen/Säkerhetspolisen.

Guess what, det nya ramverket är den gamla trotjänaren ISO 27000 fast omskrivet i arton olika delar under sex rubriker.

 

Detta är inte oväntat; i Myndigheten för samhällsskydd och beredskaps föreskrifter om statliga myndigheters informationssäkerhet (pdf) (MSBFS 2009:10) hittar vi beslutet om att alla myndigheter måste följa ISO 27000-standarden:

6 §  En myndighets arbete enligt 4 och 5 §§ ska bedrivas i former enligt följande etablerade svenska standarder för informationssäkerhet;
-  Ledningssystem för informationssäkerhet – Krav (SS-ISO/IEC 27001:2006 fastställd 2006-01-19), och
-  Riktlinjer för styrning av informationssäkerhet (SS-ISO/IEC 27002:2005 fastställd 2005-08-12).

 

Ramverket syftar alltså till att underlätta myndigheternas efterlevnad.

 

Avundsjuk på Carl-Johans läsvärda (och underhållande) skärskådningar av annat material från MSB blev jag sugen på att titta ytterligare på ramverket. Till att börja med ska vi ta en titt på "risk" under "analysera"-rubriken; riskanalys (pdf).

 

Man inleder med att konstatera att riskanalyser "används för att anpassa skyddet så att det passar verksamhetens informationstillgångar" och att det "är ett brett område" med "många metoder och teorier" men att metoden de beskriver uppfyller kraven i 27001-standarden.

 

Det viktiga i sammanhanget är att du, när analysen är genomförd; har en uppfattning om aktuella risker, om du behöver skydda dig, vilka skydd du redan har och, om de inte räcker, vilka skydd som behöver införas. Detta framgår av mallen i slutet av dokumentet.

 

Jag tycker inte att dokumentet är bra. Först och främst så tycker jag inte att den här metoden för att analysera säkerhetsrisker är effektiv. Att samla personal från olika delar av verksamheten så här och ha en workshop ger obetydlig nytta för besväret. Min erfarenhet är att det mesta som kommer fram under sådana här övningar är något som en specialist hade konstaterat och skrivit ner på tio minuter. Å andra sidan, kanske har jag varit en kass analysledare, vad vet jag.

 

Missuppfatta mig inte här, när det gäller verksamhetsrisker är det ett utmärkt sätt. Det kanske finns verksamhetsanalytiker där ute som inte håller med mig men gällande sådana risker är verksamheten en auktoritet. De vet vilka processer som är beroende av vilka andra, vilka som är nyckelpersoner, vilket verktyg det bara finns ett exemplar av, att det inte går att jobba om det börjar regna, etc.

 

Säkerhetsrisker verkar inte komma lika naturligt. Läs Schneiers essä om The Security Mindset och Ed Feltens kommentar till den. Men, åter till MSB:s dokument om riskanalys.

 

Kritik

(1) Dokumentet trivialiserar arbetet. Att tillförlitligt upptäcka och bedöma säkerhetshot är svårt. Mycket svårt. MSB framhåller istället basala detaljer som att ha post-it-lappar tillgängliga, att experter ska tala så att alla förstår och att ha god ventilation i rummet. Tydligen behöver man inte ens några ”större förkunskaper” medan ett gott råd är att bjuda på godis under analysen.

 

(2) Det man föreslår kommer att bli ett pappersmonster. Om bilaga A ska fyllas i för varje hot som en sådan analysgrupp tar fram kommer det att resultera i ett kompendium av uppskattningar multiplicerade med gissningar.

 

(3) De fördelaktiga bieffekter som föreslås komma av arbetsprocessen med riskanalyser är befängda. Att "analysgruppen tar fram en realistisk bild av verkligheten" är inte en bieffekt av arbetsprocessen, det är en förutsättning. Samma sak gäller den s k bieffekten "analysgruppen gör en realistisk och trovärdig värdering av riskerna". Möjligen att "verksamheten blir medvetna om hoten" men det förutsätter att något värdefullt kommer ut av arbetet och det är jag mer skeptisk till.

 

(4) Samtidigt som man inte nämner att sannolikhet är exceptionellt svårt att bedöma konstaterar man kallt att statistik är nödvändig information inför analysen. Information om var man hittar sådan hade varit betydligt värdefullare. Har ingen av myndigheterna som varit inblandade i framtagandet underlag?

 

(5) Förutom statistik anses "allmänna hotbilder" vara fördelaktiga. Aber Natürlich men hur sammanställer man sådana? Det vore bra information men man hänvisar inte ens till dokument där Säkerhetspolisen, på ett föredömligt sätt, diskuterar sådant. Samma lösa hållning har man för övrigt till "hotkataloger" som kan vara bra att ha "i fickan som inspiration". Är det bara jag som inte vet vad en hotkatalog är? Av allt att döma är det en parkerad, polsk domän.

 

 

Hur kan man förutsätta att någon med tillgång till relevant statistik, allmänna hotbilder och aktuella hotkataloger behöver hjälp med god ventilation och godis?

 

(6) Framförallt är följande avsnitt väldigt talande gällande min inledande kritik om att riskanalyser som de beskrivs inte är ett bra sätt att identifiera säkerhetsrisker:

 

Det är viktigt att analysdeltagarna verkligen försöker beskriva hoten så att alla förstår. I stället för att skriva "hacker" som ett hot bör man till exempel skriva "en extern angripare hackar sig in i systemet x för att ta del av uppgifterna y". Det blir då lättare att bedöma risken i kommande steg.

 

Hotet "hacker" är givetvis värdelöst, det förstår även dokumentets författare. Jag förstår däremot inte hur deras alternativ, "en extern angripare...", ska hjälpa den som är ansvarig för systemet att upprätta ett skydd. Det kan betyda precis vad som helst och är bara ett tecken på att analysgruppen (a) inte vet hur attacker genomförs och, implicit, (b) inte vet hur man skyddar mot dem.

 

Det blir inte "lättare att bedöma risken i kommande steg". Den som är ansvarig för att skyddet implementeras kommer att få hotet i knäet (av en självgod analysledare gissar jag) och får sedan själv analysera vad "hackar sig in i systemet" innebär. Det finns ju ett par olika sätt.

 

 

 

Faktumet att en hackare kanske kan försöka hacka sig in i systemet är så uppenbart att det inte behöver analyseras fram. Hur och om det skulle kunna gå till är däremot centralt. Jag får uppfattningen att analysledaren tror att de nu drog den viktiga slutsatsen att hackerskyddet på system x måste vara i läge "på" för att inte bli av med uppgifterna y. Vilken tur, annars hade vi blivit hackade.

 

Avslutningsvis

Nu har jag rejvat klart över MSB:s riskanalyser, tack för att ni stod ut med mig. Trevlig helg!

 

PS. Nej, jag garanterar att den sammansättning som föreslås i avsnitt 2.1 i dokumentet inte kommer att bryta ner "hackar sig in i systemet" till den nivå som krävs för att kunna ta åtgärder mot det.

 

PPS. Det här betyder inte att Ramverk för informationssäkerhet är dåligt, bara att dess beskrivning av riskanalyser är det. Men å andra sidan, om du bara är intresserad av efterlevnad så är det ju tydligen ett godkänt sätt.

 

--

Stefan Pettersson