Det finns alldeles för få verktyg som kan användas som stöd för informationsarbetet och det är därför i sig positivt att SKL tagit fram ett stöd för klassning. Klassning vid sidan om riskanalys den mest centrala aktiviteten för att styra informationssäkerheten vilket gör det extra intressant med ett verktyg.  Verktyget är framtaget för kommunal verksamhet med krav som ursprungligen sägs hämtade från två äldre stöd från MSB:s föregångare KBM; BITS (Basnivå för IT-Säkerhet) och BITS+. Dessa stöd togs fram 2006 och har sedan inte uppdaterats efter att ett beslut fattades redan runt 2009 att lämna BITS därhän.

Kraven har sammanställts och utvecklats till en kravkatalog som även har en koppling till ISO 27000-serien:

I samarbete mellan ett antal kommuner bearbetades kravkataloger och funktioner under våren 2015 och blev verktyget du är inne i nu. Kraven mappades om till ISO 2700x och förtydligades.

Jag bestämde mig för att göra ett test av verktyget för att se hur det fungerar i den vardagliga situation som informationsklassning är i en organisation med ett systematiskt informationssäkerhetsarbete. För att ge den som läser testet en bild av mina utgångspunkter tänker jag i detta inlägg först beskriva förutsättningarna för informationsklassning, och särskilt informationsklassning i kommunal verksamhet. Jag ska också försöka tolka KLASSA:s övergripande metodsyn.

Förutsättningar i SS-ISO IEC 27002:14

Utgångspunkten för informationssäkerhetsarbete i offentlig verksamhet är i många fall ISO-standarden, så också för mig och, om än inte direkt utsagt, för KLASSA.

Målet med klassning definieras i SS-ISO IEC 27002:14 som:

Att säkerställa att information får en lämplig skyddsnivå i enlighet med dess betydelse för organisationen.

Säkerhetsåtgärden är:

Information ska klassas i termer av rättsliga krav, värde, verksamhetsbetydelse och känslighet för obehörigt röjande eller modifiering.

Och vägledning för införande:

Klassning och tillhörande säkerhetsåtgärder för informationen bör ta hänsyn till verksamhetens behov av spridning eller begränsning av informationen samt till de legala kraven. Andra tillgångar än information kan också klassas i överensstämmelse med klassningen av den information som är lagrad i, behandlas av eller på annat sätt hanteras eller skyddas av tillgången.

Ett problem med standarden är att begreppen inte är modellerade vilket ställer till problem till exempel genom att begreppet ”tillgång” både kan användas för själva informationen och för de bärare som används för att hantera informationen som till exempel en applikation eller ett papper. Denna brist blir alltmer problematisk eftersom organisationer i allt högre grad använder molntjänster eller delar tjänster på andra sätt vilka knappast kan ses som organisationens tillgångar. Detta ska jag fördjupa mig i vid ett annat tillfälle. Här räcker det att säga att standarden tämligen tydligt säger att det är information som ska klassas. Som en följd av den klassning som gjorts av informationen kan även andra tillgångar klassas, t.ex. genom en klassning av system.

Enligt standarden ska:

Modellen för informationsklassning bör omfatta regler för klassning samt kriterier för granskning av klassificering över tid. Skyddsnivån i modellen bör bedömas genom att analysera konfidentialitet, riktighet och tillgänglighet samt andra krav för den aktuella informationen.

I 27001 finns bilaga A som ofta brukar uppfattas som en kravlista för att uppfylla standarden avsnittet A.8.2. Informationsklassning med där målet med klassningen sägs vara:

Att säkerställa att information får en lämplig skyddsnivå i överensstämmelse med dess betydelse för organisationen.

Den modell som används ska alltså inte bara innehålla beskrivning av säkerhetsåtgärder i olika skyddsnivåer utan också kriterier som för skyddsnivåer som ger en kontinuitet över tid oavsett den snabba tekniska utvecklingen. Klassningen ska kunna genomföras utifrån konfidentialitet, riktighet och tillgänglighet men också utifrån andra krav som är aktuella.

Mina egna krav

Efter att ha arbetat med informationsklassning i vitt skilda organisationer med helt olika typer av informationshantering kan jag se vissa generella krav som måste uppfyllas om klassningsaktiviteten  ska få en säkerhetshöjande effekt.

  1. Det måste vara information och organisation som är i centrum. Precis som standarden pekar på så är första steget att identifiera information, klassa den utifrån värdet och betydelsen för verksamheten inklusive betydelsen av att kunna uppfylla externa krav. Att klassa system, vilket fortfarande förekommer, ger en i mitt tycke svag verksamhetsanknytning. Detta eftersom det inte råder ett ett-till-ett-förhållande mellan verksamhet, informationsmängder och system. Det är i de allra flesta fall bara en delmängd av en verksamhets information som hanteras i samma system och det är därför svårt att få en bild av informationens betydelse och värde för verksamheten genom att bara titta på ett system. Ytterligare ett skäl att undvika att blanda samman klassning av information respektive av system kan illustreras av ett exempel jag använt flera gånger. En kommun som ska klassa konsekvenserna av att informationen om att stänga fönstren och hålla sig inomhus vid en gasolycka inte når fram till invånarna kan inte bara klassa webbplatsen. Istället måste man titta just på informationen, därefter se vilka bärare och rutiner som är lämpliga inklusive reservlösningar. Att bara titta på webbplatsen belyser helt enkelt inte situationen.
  2. Det måste finnas skyddsnivåer som är beskrivna för de bärare som används för informationen. Med det avser jag system, applikationer och it-tjänster men även krav på hur den pappersbundna hantering som alltjämt finns kvar ska ske. Skyddsnivåerna måste även innefatta krav på det fysiska skyddet som omger information och utrustning.
  3. Skyddsnivåerna måste vara beskrivna på ett konkret sätt som går att använda som en kravspecifikation både för den egna verksamheten, dels som stöd vid upphandlingar.
  4. Det måste gå att differentiera så att det görs åtskillnad på krav från de olika aspekterna konfidentialitet, riktighet, spårbarhet och tillgänglighet. Att ha höga krav på tillgänglighet innebär på intet vis att man alltid har samma höga krav på konfidentialitet. Åtgärder för uppnå det ena kan ofta motverka det andra vilket kan leda till att informationsklassning försämrar möjligheten att uppnå en anpassad säkerhet.
  5.  Det  måste det finnas en aktiv förvaltning av både krav och föreslagna skyddsåtgärder så att de inte blir vilseledande och i värsta fall kan leda till en falsk trygghet som underminerar ett systematiskt säkerhetsarbete som hela tiden måste möta nya risker.
  6.  Jag har alltid förordat att information som faller under säkerhetsskyddslagen, d.v.s. som kan på verka rikets säkerhet, ska behandlas separat eftersom det för denna information finns fastställda krav på rutiner och utrustning som ligger utanför verksamhetens normala miljö. Det är ofta lätt att identifiera denna typ av information och skapa ett separat spår för den och sedan fortsatta den övriga klassningen.

Test av KLASSA

Som användare möts man av ett fräscht och lättnavigerat gränssnitt vilket skapar förväntningar.  Jag utlovas att kunna få ”informationssäkerhetsklassa” (litet knölig term men det är kanske för att göra en distinktion mot det KLASSA som används i ett arkivperspektiv) informationen i ett verksamhetssystem, att göra en handlingsplan och att få en lista med upphandlingskrav. Redan här finns ju ett problem genom att det är ”informationen i ett verksamhetssystem” som ska klassas vilket ger en rätt föråldrad syn på relationen mellan verksamhet, information och it-lösning som jag försökt beskriva ovan.

Positivt är dock att klassa har med aspekten spårbarhet. Detta är en nödvändighet för de organisationer som har verksamhet inom vård med tanke på de krav som ställs på detta i den relativt nya föreskriften från Socialstyrelsen HSFL-FS  2016:40.

Men vilket praktiskt stöd får jag genom KLASSA? Jag tänker mig att jag klassar informationen i två olika verksamhetssystem med stor spännvidd. Det första är ett tänkt rumsbokningssystem för kommunhuset i Söpple, det andra ett vårdsystem för äldreomsorgen i samma kommun.

Jag erbjuds att klassa i fem nivåer från 0= ingen eller försumbar skada till 4= synnerligen allvarlig skada. För nivå 4 finns en oklar formulering:

Röjande av informationen medför skada för rikets säkerhet som inte endast är ringa.Systemet behandlar information som omfattas av sekretess och rör rikets säkerhet (hemliga uppgifter) där röjande av information kan ge oöverskådliga konsekvenser där t ex omfattande fara för liv och hälsa föreligger.Informationen omfattas av t ex säkerhetsskyddslagstiftningen.

Är det endast för uppgifter som är hemliga eller är det även andra uppgifter som kan utgöra omfattande fara för liv och hälsa om de röjs? Säkerhetsskyddslagen säger inget om liv och hälsa – det är andra värden som avses skyddas i den lagstiftningen. Det är inte heller rimligt att föreställa sig att sjukvård ska bedrivas med den utrustning och de rutiner som säkerhetsskyddet stipulerar (RÖS- och signalskydd för att ta ett par exempel). Detta är en besvärande oklarhet. När jag som test fyller i nivå 4 får jag till svar:

Du har klassat kravområdet Konfidentialitet som nivå 4. Kraven på dessa typer av system hanteras inte via KLASSA. Kontakta organisationens informationssäkerhetsansvarige för hantering av denna typ av information.

Jag förstår helt enkelt inte var liv och hälsa kommer in här eftersom konstruktörerna av KLASSA verkar avse endast rikets säkerhet.

För mitt rumsbokningssystem fyller jag i att det kan bli måttliga skade-effekter i alla aspekter (nivå 1) och får ut en kravlista som jag sedan kan bedöm hur väl jag uppfyller. Skadeeffekten är beskriven som:

  • Inga märkbara större svårigheter för verksamheten att nå målen.

  • Ingen påverkan på samhällsviktiga funktioner vid egen eller annan organisation.

  • Enskilda individer eller andra myndigheter och organisationer kan notera störningen eller uppleva lindriga besvär men utan påvisbar ekonomisk påverkan.

 

Med tillägget

  • Verksamhetens förmåga att utföra sina arbetsuppgifter påverkas endast i begränsad omfattning av otillgänglighet till systemet.

för aspekten tillgänglighet.

För vårdsystemet väljer jag lika konsekvent nivå 3 vilket står för:

  • Skapar stora svårigheter för organisationens verksamhet. Omöjligt eller nästan omöjligt att fullfölja uppdragen.

  • Samhällsviktiga funktioner i egen eller annan organisation påverkas sannolikt.

  • Individers liv och hälsa äventyras.

med tillägget:

  • Verksamhetens förmåga att utföra sina arbetsuppgifter påverkas i en allvarlig/katastrofal omfattning av otillgänglighet i systemet.

Jag har några synpunkter på beskrivningar av skadeeffekterna som jag väljer att hoppa över i detta redan alltför långa inlägg. Istället ska jag fokusera på det stöd jag får ut.

 

Grunden är att konstruktörerna har gått via kravbilagan till ISO 27000. Detta leder till ett stort principiellt problem och några praktiska.  Det principiella består i en underförstådd tolkning av kraven i bilaga inte ska tolkas som en helhet utan att säkerheten höjs genom ju fler av kraven som uppfylls. Detta är inte min tolkning vilken istället är att alla organisationer som eftersträvar att följa standarden ska uppfylla samtliga krav men på olika nivå beroende på sitt behov av skydd. Organisationer som certifierar sig gör ju ett Statement of Applicability (SoA) om de inte anser att kravet är tillämpbart i deras organisation.

Det praktiska resultatet av detta principiella val i KLASSA är att listan över säkerhetskrav (som numreras utifrån standarden) är betydligt kortare för rumsbokningssystemet än för vårdsystemet. Detta skulle kunna förefalla rimligt och som ett tecken på att säkerhetskraven är lägre – alltså färre krav. Jag tycker dock inte det när man ser vilka krav som saknas för rumsbokningssystemet. Exempel på vad som saknas är rena hygienfaktorer som krav på sekretessförbindelser, att identiteter inte återanvänds, styrning av loggar och uppdateringar, nätverkssäkerhet, relationen till leverantören, leverantörens åtkomst och granskning. Dessa säkerhetskrav påverkar ju inte enbart rumsbokningssystemet utan i värsta fall hela miljön som de finns i.

Att KLASSA tar sin utgångspunkt i standardens krav i sin rena form i de flesta fallen (undantag är till exempel identifieringslösningar) leder till den litet paradoxala följden att det ställs mycket få tekniska krav trots att det är system som klassas. Det leder också till att kraven är mycket öppna för tolkning och inte till någon större hjälp vare sig intern eller vid upphandling som till exempel:

 Information tillhörande systemet som lagras på externa molntjänster eller på flyttbar lagringsmedia, exempelvis mobiltelefoner, USB-minnen och externa hårddiskar, hanteras och skyddas på motsvarande sätt som övrig information tillhörande systemet.

Eller ur det excelark som kan användas som stöd för upphandling:

Leverantören ska ha en rutin för att både avaktivera användarkonton och permanent ta bort konton från systemet.

En sammantagen bedömning

Trots att behovet är stort och ansatsen tycker jag inte att KLASSA är ett bra verktyg. I vissa fall skulle jag till och med säga att det är en riskfaktor i sig eftersom KLASSA på de lägre säkerhetsnivåerna plockar bort så många självklara säkerhetsåtgärder att ett system som sägs uppfylla kraven kan vara i avsaknad av elementära säkerhetsåtgärder. Detta är en risk i systemet och i värsta fall för hela it-miljön som det finns i. Om en leverantörs åtkomst inte är styrd och begränsad i ett system kan det leda till obehörig åtkomst även i andra integrerade lösningar för att bara ta ett exempel.

Av de sex krav jag ställde upp fyller KLASSA endast delvis upp krav 2, 4 och 6 om man gör en välvillig tolkning.

Jag hoppas SKL gör ett omtag och då även ser över till exempel kraven från dataskyddsförordningen och integrerar även dem.