It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Tagg: säkerhetskrav

Det finns inga gratiskrav

Det finns inga gratiskrav.Det här är en post-it som sitter strax till höger om min skärm vid skrivbordet. Den är till för att påminna mig om att påminna personer i min närhet om att ”Det finns inga gratiskrav”.

I mina ögon är säkerhetskravställning lite av en konst. Inte för att det är svårt, på sätt och vis är det ganska enkelt att ställa säkerhetskrav: det finns en hel industri kring it-säkerhet som har tagit fram saker från säkerhetsövervakningsavdelningar till MAC och allt där i mellan.

När du sitter med ett system under utveckling och ska formulera säkerhetskrav har du hur många krav som helst att välja på. Häri ligger konsten, du kan inte ställa hur många som helst för förr eller senare ska kraven uppfyllas; någon ska implementera MAC-kontrollen eller organisera säkerhetsövervakningsavdelningen och det kostar resurser i tid och pengar.

Att välja säkerhetskrav

Varje säkerhetskrav kostar resurser och sådana är alltid begränsade. Konsten är att ställa de säkerhetskrav som ger mest bang for the buck. Säkerhetskrav kostar olika mycket resurser och bidrar med olika mycket säkerhet så i grunden handlar det om en cost/benefit-analys för varje krav.

Är den säkerhet som kravet bidrar med värd besväret?

För att kunna svara på denna fråga måste man har koll på tre saker:

  1. Vad kostar kravet?
  2. Hur mycket säkerhet ger kravet?
  3. Vilket behov av säkerhet finns?

Tyvärr finns inga exakta svar på någon av frågorna, det finns inte ens ganska exakta svar, så vi kan sällan räkna på det med siffror. (Jag refererar till två äldre inlägg: Att mäta säkerhet på Internetdagarna och Att mäta säkerhet igen.)

Jag sprang på ett fantastiskt citat igår kväll på tal om det här, ett av ekonomilegenden Keynes (nu såg jag att det inte alls var han utan tydligen Carveth Read):

It is better to be vaguely right than exactly wrong.

Det kommer att handla om olika bra uppskattningar till svaren. Man ska göra avvägningen i alla fall; men man måste acceptera att det inte är en exakt vetenskap och handla därefter. Det här leder ofta till något som det är modernt att hata inom säkerhet; något som slarvigt kallas magkänsla. Jag gnäller en del över det i Att mäta säkerhet igen-inlägget om du är på humör för sånt, annars lägger vi det åt sidan.

Av de tre frågorna följer att alla säkerhetskrav inte är lika mycket värda. Vissa saker ger mycket säkerhet för lite resurser medan andra ger förhållandevis lite säkerhet i utbyte mot stora resurser. De förstnämnda är no-brainers, de sistnämnda kräver analys; kanske är just den lilla säkerhetsdetalj som erbjuds ett måste som inte går att uppnå på något annat sätt? Kanske kan vi inte avgöra riktigt utan blir tvungna att köra för att vara på säkra sidan?

Rabatt på säkerhetskrav

När vi ändå har börjat tala i ekonomiska termer kan vi lika gärna fortsätta, men det får bli nästa gång. Trevlig tredje advent!

Toppdomänen .secure

Bolaget Artemis Internet Inc. är en av de första att utnyttja den nya möjligheten att registrera en godtycklig toppdomän hos ICANN. Artemis ägs helt av NCC Group som också äger iSEC Partners. De senare är några som åtminstone jag länge har haft respekt för även om jag, nu när jag skriver det, är osäker på varför. Enligt utsago är toppdomänen .secure en idé från just iSEC-gänget.

Tanken med deras nya toppdomän .secure (som tydligen inte är godkänd ännu) är att den ska utgöra en tryggare del av internet. För att bli ägare av en domän under .secure måste man nämligen uppfylla ett antal krav:

Ansökningar kommer att behandlas på samma sätt som vid certifikatansökningar, Artemis kommer att kontrollera att du är den du utger dig för att vara innan du får köpa en domän. Information om vem som äger domänen kommer sedan att vara tillgänglig för besökare (på något ”innovativt” sätt). Det verkar som att man, till skillnad från certifikatmånglarna, verkligen kommer att ta det på allvar:

Address verification will be performed using the delivery of a physical two-factor authentication token to a publicly listed corporate address. Each domain issued under .SECURE will need to be approved by a full-time employee of Artemis, and vigorous authentication of identity will be performed during any change of control or ownership.

Domänägare kommer att behöva följa en särskild kodex samt ett gäng säkerhetskrav. Kodexen verkar vara något i stil med att lova att inte sprida malware eller motsvarande. Kraven kommer åtminstone omfatta obligatorisk DNSSEC för namnservrar, TLS för kommunikation för webb och mail samt även DKIM för mail. Tanken är att:

These policies will strictly prevent the intentional use of .SECURE domains for malicious activity or the inadvertent creation of vulnerability through misapplication of security technologies.

Man kommer kontinuerligt att granska domäner för brott mot kodex och säkerhetskrav. Förbrytare ska stängas av snabbt.

Allt det här är alltså tänkt att falla under deras catch-phrase: verify, secure, enforce.

Det är oklart vilka övriga säkerhetskrav som kommer att ingå men de beskrivs tydligen som ”meningsfulla”. Om Artemis förväntar sig kunna verifiera att kraven uppfylls (enforce) så begränsas antalet möjliga krav att ställa. Hur ska de t ex kunna verifiera att servrar har antivirusprogram? Jag därför svårt att tänka mig krav i stil med PCI DSS eller ens i närheten av det.

Priset för en domän är inte satt men av allt att döma kommer det att vara dyrt.

På samma sätt som .info har legat högt upp på listor som ”the most dangerous top-level domains” kommer .secure att ligga långt ner.

Toppdomänerna .edu, .mil och .gov ligger ju också långt ner; för att de är (1) dyra och/eller (2) begränsade till vissa organisationer. Den nya .secure-domänen kommer att erbjuda samma sak för vanliga organisationer och företag. Det är det stora bidraget, de övriga säkerhetskraven som ställs (TLS, DNSSEC o s v) är inte lika viktiga.

Det ska bli intressant att se om .secure slår.

Säkerhetskravställning är sexigt — del 1

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.

Riskanalys à la MSB

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.

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å alla håll och kanter. 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.