KSF – The Dark Side

I ett tidigare blogginlägg gav jag en lättare introduktion till godkända säkerhetsfunktioner med fokus på några assuransfrågor. Nu kommer fortsättningen. Hur bra är KSF 3.1 och vilka svårigheter finns att uppfylla kraven?

Evalueringsmetodik saknas

Utdrag ur sidan 25 i bilaga 1 i KSF 3.1.

Hur granskning av ett IT-system ska genomföras för att verifiera att säkerhetsförmågor och säkerhetskrav är riktigt identifierade och att systemet uppfyller dem beskrivs i en evalueringsmetodik, enligt KSF 3.1. Där beskrivs också hur en evaluering ska dokumenteras. Syftet med evalueringsmetodiken är att säkerställa att evalueringar genomförs och dokumenteras på ett enhetligt sätt och med tillräcklig kvalitet.

Evalueringsmetodiken finns enligt KSF 3.1 i en evalueringsmanual, ett separat dokument skilt från KSF 3.1. Det är bara ett problem – evalueringsmanualen existerar inte. Det betyder att det saknas en ledstång för hur evalueraren ska granska ett IT-system, hur bedömningar ska genomföras och hur evalueringar ska dokumenteras. Trots att det har gått fyra år sedan KSF 3.1 beslutades finns det inte någon evalueringsmanual. Det innebär att evalueringar inte genomförs och dokumenteras på ett enhetligt sätt eller med tillräcklig kvalitet.

Utbildning genomförs inte

Utdrag ur sidan 2 i beslut om KSF 3.1.

KSF 3.1 är en komplicerad uppsättning krav där assuranskraven är svårtillgängliga även för IT-säkerhetsexperter. Men utbildning i hur KSF ska användas existerar inte. Det finns inte ens exempel på lämpligt innehåll i en IT-säkerhetsspecifikation (ITSS).

Förvaltning existerar inte

Utdrag ur sidan 2 i beslut om KSF 3.1.

KSF 3.1 innehåller slarvfel i form av felnumrerade krav (sidorna 46-47 i underbilaga 1:4). Dessa enkla förbättringsbehov har inte omhändertagits sedan KSF 3.1 beslutades för fyra år sedan. Under tiden har även hoten förändrats. Som NSA-ordspråket säger:

”Attacks always get better; they never get worse.”

Någon förvaltning av KSF 3.1 existerar inte, trots att omvärldsförändringar och hot pekas ut som skäl för regelbunden förändring. Det räcker inte med att moment ge ut krav – man måste också ta hand om dem.

Vägledning för alternativa sätt att uppfylla krav saknas

Ett funktionellt säkerhetskrav kan uppfyllas genom tekniska åtgärder i systemet (A i figuren nedan) eller genom att utnyttja egenskaper i driftmiljön (B i figuren nedan) eller genom en kombination av åtgärder och egenskaper (C i figuren nedan).

Funktionella säkerhetskrav i KSF 3.1 kan uppfyllas genom tekniska åtgärder (A), egenskaper i driftmiljön (B) eller en kombination (C).

Egenskaper i driftmiljön (systemets omgivning) kan enligt KSF 3.1 vara av ”geografisk, fortifikatorisk, personell eller administrativ karaktär”. Ett enkelt exempel skulle kunna vara att den fysiska säkerheten används för att begränsa åtkomsten till delar av ett IT-system. Dessa egenskaper i driftmiljön är då ett alternativt sätt att uppfylla vissa av de funktionella säkerhetskraven för säkerhetsfunktionen behörighetskontroll.

Det är systemutvecklarens ansvar att påvisa att de funktionella säkerhetskraven är uppfyllda och hur de har uppfyllts. Problemet här är att det saknas konkreta exempel. Vägledning för alternativa sätt att uppfylla funktionella säkerhetskrav existerar inte. I kombination med att en evalueringsmanual inte existerar riskerar KSF 3.1 uppmuntra ett säkerhetsarbete där systemutvecklaren hävdar kravuppfyllelse genom att hänvisa till påståenden om egenskaper i driftmiljön utan det finns någon verklig säkerhet bakom.

Okända tillkommande säkerhetskrav

De funktionella säkerhetskraven i KSF 3.1 missförstås ofta som en komplett kravmassa för IT-säkerhet. Om man funderar lite över tillgänglighetsaspekten så inser man snart att kraven endast omhändertar konfidentialitetsaspekten – och då endast en delmängd av krav på skydd för konfidentialitet. Som jag skrev i det tidigare blogginlägget finns det en obligatorisk plats för tillkommande säkerhetskrav i IT-säkerhetsspecifikationen (ITSS).

Problemet här är att det saknas en uttömmande beskrivning över vilka krav som minst måste ingå som tillkommande säkerhetskrav, om ett IT-system ska hantera hemlig information. I H SÄK Infosäk visade jag på några källor till tillkommande säkerhetskrav. Därmed blev jag också en del av problemet, ingen kan visa upp en uttömmande förteckning över tillkommande säkerhetskrav. Den bakomliggande orsaken är att krav på informationssäkerhet i IT-system för hemlig information fortfarande utgår från hur pappershandlingar ska skyddas.

En källa för tillkommande säkerhetskrav är krav från en hot-, risk- och sårbarhetsanalys för IT-systemet (eller säkerhetsanalys som är det begrepp som numera används i Försvarsmakten). Hot som är omhändertagna av de sju säkerhetsfunktionerna behöver vanligtvis inte ges någon större uppmärksamhet i en säkerhetsanalys. Kraven i KSF är, enligt KSF 3.1, anpassade mot dimensionerande hot. Problemet här är att det inte är uppenbart vilka dimensionerande hot som KSF omhändertar. Det försvårar avgränsningar i en säkerhetsanalys och arbetet att identifiera hotrelaterade krav som inte täcks in av KSF.

Obegripliga krav

Utdrag ur sidan 36 i underbilaga 1:4 i KSF 3.1.

Läs det här assuranskravet några gånger och försök sedan förklara för en systemutvecklare vad som ska dokumenteras.. Merparten av kraven i KSF 3.1 är begripliga, men några är svåra att förstå eller rent av obegripliga. Samtidigt är det krav som ska uppfyllas. Att det saknas en evalueringsmanual gör det heller inte lätt för en evalurerare att bedöma kravuppfyllnaden. I detta exempel måste någon dokumentation tas fram, men för alla inblandade kommer det vara oklart vilket innehåll som uppfyller kraven.

Lämpliga designval ligger utanför KSF

Vilka tekniska arkitektur- eller designval som är lämpliga ur säkerhetssynpunkt anges inte i KSF. Ett exempel är virtualisering av IT-system.

Virtualisering där den virtualiserade miljön motsvarar fysiska dator, är en beprövad och vanligt förekommande lösning som ger driftsmässiga och ekonomiska fördelar. Med virtualisering byts en fysisk separation mellan datorer ut mot en logisk mjukvarubaserad separation. Det leder till en större exponering mellan datorerna och att separationen blir svagare, än om datorerna hade varit fysiskt åtskilda. Hypervisorn (det program som låter flera operativsystem dela på samma hård­vara) är en säkerhetskomponent som ska förhindra såväl intrång som läckage mellan virtuella datorer. Men dagens virtualiseringstekniker är inte tillräckliga som en sådan skyddsbarriär.

MUST har gett ut en vägledning om säkerhet och virtualisering. Enligt vägledningen uppfyller inte hypervisorer de krav som ställs på en separationsmekanism mellan olika informationssäkerhetsklasser eller mellan olika säkerhetsdomäner.

Exemplet med virtualisering visar att enbart kraven i KSF 3.1 inte är tillräckliga som stöd för att utveckla IT-system med tillräckliga säkerhetsförmågor. Det behövs även andra krav eller råd som kompletterar kraven. Sådana krav eller råd måste kommuniceras så att alla inblandande har kunskap om existensen och innehållet.

≈ ≈ ≈

I det här inlägget gav jag några perspektiv på baksidorna med KSF. Det finns fler.

De olika KSF-versionerna har varit positiva milstolpar i synsätt och kravställning på IT-säkerhet för hemlig information (rikets säkerhet). Men kraven är inte felfria och utan evalueringsmanual är KSF inte komplett. Någon ständig förbättring är inte möjlig eftersom förvaltning saknas. De som ska använda KSF har en lång startsträcka då utbildning saknas. Jag hoppas att kommande version av KSF blir bättre och att förutsättningar för förvaltning och utbildning skapas. Det skulle gynna alla som arbetar med frågorna.

Källor:

  • Beslut om krav på godkända säkerhetsfunktioner version 3.1 (2014-06-13 FM2014-5302:1) (PDF på FM webbplats, PDF på FMV webbplats för ISD).
  • Avsnitt 14.4 i H SÄK Infosäk om säkerhetsanalys som källa för tillkommande säkerhetskrav (PDF).
  • FOI-rapporten Risker med virtualisering av IT-system (FOI-R–4448–SE) (sammanfattning) (PDF).

/Kim Hakkarainen

1 kommentar

Publicerad i IT-säkerhet, Säkerhetsskydd

En kommentar till KSF – The Dark Side

  1. Petter Claesson

    Tack för din utmärkta analys. Gillar speciellt att du lyfter fram att detta måste fungera i ett livcykelperspektiv. mvh, Petter

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.