IT-säkerhet enligt HPS

Jag har tidigare skrivit att drift är osexigt. Implicit ska det finnas ett "tyvärr" framför "osexigt" eftersom mitt argument är att en stor portion av säkerheten vilar på driften. Drift är tyvärr osexigt.

Kravställning på säkerhet har också problem med sin sexuella utstrålning, problemet är dock annorlunda. Säkerhetskravställning är just nu som den där lite töntiga tjejen med troende föräldrar, goda betyg, uppsatt hår och glasögon som vi ofta ser i amerikanska collegefilmer. (Nedan illustrerat med Not Another Teen Movie.)


Det är dags för säkerhetskravställning att ifrågasätta sin uppfostran, släppa ut håret, sminka sig lite och byta till kontaktlinser.


Fenomenet kallas populärt för the ugly duckling syndrome och är precis vad säkerhetskravställning behöver och kommer att genomgå.

God säkerhetskravställning är något vi är sällsynt oförmögna att göra. Det är samtidigt ett område inom säkerhet som inte hålls särskilt högt trots att det är centralt för många. Jag tror att det är p g a vår oförmåga. Med rätt inställning till kravställningen kommer det att kunna konkurrera med penetration testing, vulnerability analysis, source code review, threat modeling och de andra populära ungdomarna i klassen.

Vi måste först lösgöra oss från torrheter som "författningskrav" och "efterlevnad", synnerligen oattraktivt, och ersätta dem med hetare motsvarigheter.

Alltså, om vi börjar ställa säkerhetskrav ordentligt kommer vi att effektivisera säkerheten och uppfattas som attraktivare. Enkelt.

Säkerhetskrav
I verkligheten finns bara två sorters säkerhetskrav:

1. de som måste uppfyllas oavsett om de behövs eller inte och
2. de som måste uppfyllas för att de behövs.

Ursäkta klarspråket men (1) den första sorten kommer huvudsakligen från lagar, förordningar, föreskrifter, regler, tillsynsorgan, standardorgan, kunder, leverantörer och andra entiteter som man inte kan påverka själv. (2) Den andra sortens krav kallas här hotrelaterade eller hotbaserade, det är krav som ställs för att skydda mot något som är relevant att skydda mot. För att de behövs.

Ett grovt exempel skulle vara att du som husägare, enligt någon av landets lagar, måste skydda ditt hem mot stormande elefanthjordar; även om huset står på en ö där det inte finns elefanter. Lagen tvingar dig att bygga höga murar, odla höga häckar eller installera dyra, elektroniska elefantvarnare; i onödan. Samtidigt kanske området har problem med inbrottstjuvar varför ett larm och ett ordentligt lås på balkongdörren vore lämpligt. Det säger däremot inte lagen något om. Du installerar elefantvarnare för att inte bryta mot lagen, inte för att varna för elefanter. Detta kallas för compliance-driven security och borde ses som en förolämpning.

Något mer verklighetsförankrat: om du tar betalt med kort så måste du ha antivirusprogram installerade, oavsett om det skyddar mot något du behöver skydda dig mot eller inte. Det säger nämligen PCI DSS:

5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Samma sak gäller om du är en myndighet och behandlar uppgifter som har bäring på rikets säkerhet. Det säger nämligen Rikspolisstyrelsens föreskrifter och allmänna råd om säkerhetsskydd (pdf):

4 kap. 19 § Ett IT-system, som är avsett för behandling av hemliga uppgifter eller som särskilt behöver skyddas mot terrorism, ska vara försett med av myndigheten godkänt skydd mot skadlig kod.

Det kan ju förstås vara så att antivirusprogram behövs på grund av att det skyddar mot ett hot som du är oroad över. De två sorterna av säkerhetskrav kan alltså överlappa.

Situationen kan illustreras med ett venndiagram (se nedan). Blått fält motsvarar de egentliga behoven av säkerhetskrav, grönt fält de krav som identifierats utifrån hot och rött fält obligatoriska krav. Här har jag som synes redan gjort antagandet att hotrelaterade krav är bättre på att möta upp mot behoven än vad de obligatoriska kraven är. Några saker att notera:

1. Det är omöjligt att helt täcka de egentliga (blåa) behoven.
2. Det är omöjligt att inte få med onödiga krav (utanför det blåa).
3. Obligatoriska (röda) och hotrelaterade (gröna) kan överlappa.

Från diagrammet framgår det (övertydligt) att de obligatoriska (röda) kraven till stor del (omkring hälften i bilden) är onödiga (ligger utanför det blåa fältet). Förutsatt att mitt antagande stämmer, att de hotrelaterade (gröna) kraven kan ge betydligt mer bang for the buck. Varför har vi då obligatoriska krav?

Jo, de externa entiteterna tror inte att vi är förmögna att skapa en tillräckligt stor grön cirkel som är tillräckligt väl placerad över den blåa. Varken PCI eller Rikspolisstyrelsen litar på att vi kan identifiera behovet av antivirusprogram ifall det finns så de ställer kravet "för säkerhets skull". Jag brukar kalla det bombmatta.

Självklart kan detta leda till att de obligatoriska kraven blir onödigt omfattande (Dodd-Frank någon?). Med andra ord: de går utanför behoven så mycket att det inte är värt det.


I del två av inlägget försöker jag försvara antagandet lite utförligare och går in på vad vi saknar för att ta fram lämpliga säkerhetskrav, d v s se till att den gröna cirkeln är bättre anpassad till den blåa än den röda är. Jag är dock rädd att det är lite mer invecklat än kontaktlinser, foundation och maskara.

--
Stefan Pettersson

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

I juli 2010 införde amerikanarna en ny lag: Dodd-Frank Wall Street Reform and Consumer Protection Act. Dodd-Frank ska reglera finansmarknaden, tydliggöra ansvar, öka transparens och skydda medborgare från att i framtiden behöva rädda banker som hamnat i ekonomiskt obestånd p g a orimlig riskexponering.

Med subprime-idiotin i bakvattnet är Dodd-Frank förståelig. Men även om avsikten är god så kan genomförandet halta. I förra veckans the Economist (bl a Over-regulated America och Too big not to fail) beskrivs Dodd-Frank och omdömet är sådär. Huvudsakligen kretsar kritiken kring att lagen är (1) för omfattande, (2) för komplicerad och (3) kräver mycket energi för att följa. Min fetstil:

But Dodd-Frank is far too complex, and becoming more so. At 848 pages, it is 23 times longer than Glass-Steagall, the reform that followed the Wall Street crash of 1929. Worse, every other page demands that regulators fill in further detail. Some of these clarifications are hundreds of pages long. Just one bit, the "Volcker rule", which aims to curb risky proprietary trading by banks, includes 383 questions that break down into 1,420 subquestions. [...] Hardly anyone has actually read Dodd-Frank, [...]

Som vanligt är jag ju ute på djupt vatten här när jag kommenterar amerikansk finanslagstiftning men Dodd-Frank är ett perfekt exempel på något som gör mig trött: onödig komplexitet.

Komplicerade system — oaktat om det är lagar, mailservrar, flygplatser eller scriptfiler...

• har effekter som är svåra att förutse,
• har förmodligen oväntade bieffekter,
• tar lång tid att förstå sig på,
• är svåra att göra kontrollerade ändringar i,
• är jobbiga att granska,
• är krångliga att optimera,
• är problematiska att avveckla,
• är hemska att felsöka och
• saknar elegans (hemska tanke).

N.B. Allt är dock inte negativt; det är fullt möjligt att komplicerade system går snabbare att designa än enklare system med motsvarande funktionalitet. Enkla lösningar är i regel svårare att tänka sig än de som är onödigt sammansatta. I övrigt är de dock bättre på alla sätt man kan tänka sig.

Beroende på vem du är kan i o fonödig komplexitet vara en fördel; amerikanska jurister gnuggar sannerligen händerna över Dodd-Frank...

Komplexa system riskerar alltid s k emergent properties (ungefär framväxande egenskaper) vilket är samma sak som överraskande bieffekter men avser just interaktion mellan olika delar av komplexa system. Definitivt inte önskvärt i säkerhetssammanhang. Schneier återkommer till det här många gånger i sin bok Beyond Fear; en av mina biblar. Jag är multireligiös.

Det mest bedrövande med just Dodd-Frank är att det är en lag. Lagar skyddar mot oönskade handlingar. Lagar är säkerhetssystem. Allt som kan angripas är säkerhetssystem. De kan således ha sårbarheter eller säkerhetshål; även om de i lagsammanhang oftast kallas kryphål (oklart varför).

Det ironiska är att den onödiga komplexiteten förmodligen har ökat med försöken att eliminera just kryphålen. Samtidigt säger den fundamentala lagen om säkerhet och enkelhet att antalet sårbarheter/kryphål måste öka med komplexiteten.

Kanske var det bättre förr, som en juristkollega sade, när en bra domare ansågs stå över en dålig lag.

--
Stefan Pettersson