Utveckling av säkra IT-produkter med Common Criteria

Skyddsåtgärder, evaluering och certifiering

Med hjälp av en hot- och riskanalys analyseras och fastställs behov av skyddsåtgärder. Enligt CC ställs kraven på säkerhet utifrån två aspekter:

• Skyddsåtgärder – vilka skyddsåtgärder behövs för att möta hoten
• Assuranskrav – hur noggrant bör skyddsåtgärderna evalueras och certifieras?

Enligt CC uttrycks krav på säkerhet i:

• Skyddsprofiler (engelska: Protection Profiles, PP) som beskriver köparens önskemål och krav generellt för en viss typ av IT-produkter.
• Säkerhetsmål (engelska: Security Targets, ST) som beskriver leverantörens utfästelser för en viss IT-produkt.

Enligt CC organiseras skyddsåtgärder i klasser, familjer, komponenter och element. Följande klasser för skyddsåtgärder1 finns (de tre första bokstäverna anger klassens namn):

• FAU - Logghantering
• FCO - Kommunikation
• FCS - Kryptografiskt stöd
• FDP - Användarintegritet
• FIA - Identifiering/autenticering
• FMT - Administration av säkerhetsfunktioner
• FPR - Skydd av användardata
• FPT - Skydd av säkerhetsfunktioner
• FRU - Resursutnyttjande
• FTA - Kontroll av sessionsetablering
• FTP - Kontroll av identiteter vid kommunikation

Evaluering

Enligt CC organiseras evalueringskrav i aktiviteter, subaktiviteter och arbetsenheter vilka är samordnade med assuranskravens klasser, familjer och komponenter. Vilka krav som ska ställas vid evaluering3 av en specifik IT-produkt definieras genom vilken assuransnivå som angetts i säkerhetsmålet.

Ett av det nationella certifieringsorganet (engelska: Certification Body, CB) licensierat evalueringsföretag (engelska: IT-Security Evaluation Facility, ITSEF) granskar om de anspråk på ITprodukten som leverantören har angett i säkerhetsmålet eller kunden angett i skyddsprofilen stämmer med verkligheten. När evalueringsföretaget granskar överensstämmelsen mellan IT-produkten och säkerhetsmålet eller skyddsprofilen använder det till exempel någon eller några av följande metoder:

• Analys av processer och procedurer vid utveckling av IT-produkten samt kontroll av att dessa processer och procedurer tillämpats.
• Analys av konstruktionsdokument som jämförs med de krav som anges i säkerhetsmålet eller skyddsprofilen samt analys av korrespondensen mellan olika abstraktionsnivåer i dokumentationen (funktion, högnivådesign, lågnivådesign).
• Analys av funktionella tester och testresultat som har genomförts av leverantören samt analys av användardokumentation.
• Oberoende funktionell testning, genomförd av evalueringsföretag samt sårbarhetsanalys eller penetrationstest.

I Sverige finns idag (2011) två av FMV/CSEC licensierade evalueringsföretag:

atsec information security AB
www.atsec.org
Svärdvägen 11
182 33 Danderyd

Combitech
www.combitech.se
351 80 Växjö

Assurans

Enligt CC organiseras även assuranskraven i klasser, familjer, komponenter och element. Följande klasser är aktuella (de tre första bokstäverna anger klassens namn):

• APE - Utvärdering av skyddsprofiler
• ASE - Utvärdering av säkerhetsmål
• ADV - Utveckling
• AGD - Användardokumentation
• ALC - Life-cycle support
• ATE - Tester
• AVA - Sårbarhetsanalys
• ACO - Composition (samordning/kombination)

Inom CC är assuranskomponenterna paketerade i sju assuransnivåer (engelska: Evaluation Assurance Level, EAL). EAL 1 är den lägsta nivån och EAL 7 den högsta.

• Från EAL 1 till och med EAL 4 används i ökande grad metoder som kontrollerar dokumentation, funktionalitet och överensstämmelse med implementationen.
• Från och med EAL 5 ställs krav på hur produkten är konstruerad, för att slutligen vid EAL 7 även omfatta krav på formella bevis på att produkten är framställd enligt specifikationen.

Utgångspunkten har varit potentiella hot enligt följande tänkta skala:

• EAL7 - Fientligt sinnad konstruktör - insider hos utvecklaren
• EAL6 - Främmande makt
• EAL5 - Kvalificerad programmerare
• EAL4 - Hacker eller programmerare
• EAL3 - Erfaren användare
• EAL2 - Intresserad användare
• EAL1 - Nyfiken användare

Den valda assuransnivån kan bero på många faktorer som till exempel tillgångarnas skyddsvärde, vilken säkerhetsmiljö och hotbild som är aktuell, vilken budget som finns tillgänglig och hur benägen man är att ta risker. Genom assuransnivåerna ges aktörerna ett verktyg för att balansera behovet av tillit till IT-produkten mot de kostnader det medför att genomföra en evaluering.

Låg assurans och kostnader

En evaluering på assuransnivå EAL 4 och uppåt kan medföra betydande kostnader då detta även omfattar analys av bland annat konstruktionsdokument och källkod. För en mer komplex IT-produkt kan kostnaden uppgå till miljontals kronor.

För de allra flesta IT-produkterna medför en evaluering på assuransnivå EAL 1 en begränsad kostnad men kan ändå ge ett rimligt värde för systemägaren. Dessutom kan man använda ett säkerhetsmål för låg assurans som är mindre kostnadskrävande att producera.

• Ett certifikat enligt EAL 1 anger tydligt under vilka förutsättningar leverantören avser att IT-produkten ska kunna användas säkert och vilken grundläggande testning som genomförts.

För en person eller organisation som inte finner lämpliga CC-certifierade IT-produkter eller skyddsprofiler på CC-portalen och som av något skäl, till exempel begränsningar i tillgänglig tid eller ekonomi, inte kan utveckla egna skyddsprofiler finns ändå möjligheter att upphandla IT-produkter som kan antas ha en rimlig säkerhetsnivå med hjälp av CC. Detta åstadkoms genom att organisationen ställer krav på

• att leverantören av en IT-produkt minst tillhandahåller ett säkerhetsmål som är certifierat enlig CC.

Fördel vid upphandling bör ges till

• IT-produkter som är på väg att CC-certifieras och som minst har ett säkerhetsmål som motsvarar de önskade kraven.

Certifiering

Resultatet av en evaluering kan fastställas av ett certifieringsorgan som även har till uppgift att övervaka ett evalueringsföretags rutiner, metoder och kompetens.

Enligt CC evalueras och certifieras ITprodukter enligt en process som kan sammanfattas på följande sätt:

• Leverantören skickar ITprodukten med tillhörande dokumentation till ett licensierat evalueringsföretag (ITSEF).
• Evalueringsföretaget granskar dokumentationen och testar produkten gentemot säkerhetsmålet eller skyddsprofilen samt skriver en evalueringsrapport.
• Det nationella certifieringsorganet (CB) övervakar och godkänner evalueringsföretagets arbete och publicerar ett certifikat.

Slutresultatet, certifikatet med tillhörande rapport, anger bland annat:

• En angripares antagna förmåga att hitta svagheter i systemet samt vilka informationssäkerhetsrelaterade hot som förväntas.
• Vilka policies och regler produkten uppfyller, vilka säkerhetsmekanismer som används för att möta hoten samt vilken säkerhetsarkitektur som systemet har.
• Styrkan på säkerhetsmekanismerna samt hur noggrant säkerhetsmekanismerna har granskats och verifierats – assuransnivån.
• Villkor för hur IT-produkten på ett säkert sätt ska sättas i drift samt krav på omgivningen för att säkerheten ska upprätthållas.

Nedanstående symbol ska finnas på alla CC -certifikat.

Kravanalys, säkerhetsmål och skyddsprofiler

Översiktlig modell för kravanalys

I detta avsnitt presenteras en översiktlig modell för hur hot/risk, säkerhetspolicy inkluderande lagar och förordningar samt antaganden om övriga förutsättningar kan sammanfattas. Denna information utgör underlag för att kunna uttrycka skyddsåtgärder och assuranskrav som därefter används för att formulera säkerhetsmål och skyddsprofiler enligt CC.

Resultatet av en evaluering enligt CC är i hög grad beroende av hur noga säkerhetsproblematiken är analyserad och definierad. Det är därför oftast väl värt den investerade tiden att genomföra en noggrann analys kring detta. Nedan visas den översiktliga modellen:

Med hot avses här de hot som riktas mot den IT-produkt som ska evalueras och mot produktens operativa miljö. Med säkerhetspolicy avses den internpolicy och/eller de lagar och förordningar som gäller där den aktuella IT-produkten och dess operativa miljö finns. Med antaganden om övriga förutsättningar avses utformningen av den operativa miljön vilket kan omfatta till exempel fysisk utformning och personal. Vid en evaluering enligt CC förutsätts alltid de aktuella antagandena vara uppfyllda och de evalueras inte.

Komponenter och paket

Skyddsåtgärder och assuranskrav byggs upp av motsvarande komponenter som i sin tur är organiserade i familjer och klasser men kan även vara fritt kombinerade i paket. Detta illustreras nedan:

Klassernas namn anges med tre versala bokstäver, till exempel FMT (Security Management). Familjerna inom varje klass anges med ett ”underscore” och ytterligare tre versala bokstäver, till exempel FMT_SMR (Security Management Roles). Familjernas komponenter är numrerade, till exempel FMT_SMR.1 och så är även komponenternas element, till exempel FMT_SMR.1.1.

Ett paket kan bestå av krav som avser säkerhet eller assurans men inte en kombination av dessa två. Ett paket kan kombineras och användas fritt till exempel för att konstruera större paket som i sin tur kan vara säkerhetsmål eller skyddsprofiler.

Säkerhetsmål

För att kunna evaluera en IT-produkt (TOE) används inom CC en konstruktion som kallas säkerhetsmål (ST). I säkerhetsmålet beskrivs den aktuella IT-produkten och hoten mot denna, därefter beskrivs vilka åtgärder - säkerhetsfunktioner och assuranskrav - som behövs för att möta hoten och sedan leds i bevis varför dessa funktioner är tillräckliga för att möta hoten.

I ett säkerhetsmål beskrivs två typer av säkerhetsfunktioner enligt följande:

• säkerhetsfunktioner som avser den aktuella IT-produkten (TOE) utgående från hotbilden och säkerhetspolicyn
• säkerhetsfunktioner som avser den operativa miljö där produkt verkar

En evaluering enligt CC avser endast skyddsåtgärder för den aktuella IT-produkten.

I det följande beskrivs hur ett säkerhetsmål är uppbyggt och vad det måste innehålla:

Före och under en evaluering utgör säkerhetsmålet en specifikation av vad som ska evalueras. Efter evalueringen utgör säkerhetsmålet en specifikation av vad som har utvärderats och kan därför också utgöra ett underlag för avtal mellan utvecklaren/säljaren och den blivande kunden/användaren av den aktuella IT-produkten. I säkerhetsmålet finns IT-produktens säkerhetsegenskaper beskrivna på ett övergripande och tydligt sätt vilket medför att kunden/användaren kan lita på detta eftersom IT-produkten har blivit evaluerad mot det aktuella säkerhetsmålet.

Säkerhetsmål för låg assurans

Att skriva ett säkerhetsmål kan innebära ett mycket omfattande arbete och kan i samband med en evaluering med låg assurans utgöra huvuddelen av arbetsinsatsen. Av den anledningen finns inom CC möjligheten att använda säkerhetsmål för låg assurans. Detta avser endast evaluering på assuransnivå EAL 1. Ett säkerhetsmål för låg assurans behöver inte innehålla familjerna ASE_SPD Security Problem Definition och ASE_OBJ Security Objectives.

Skyddsprofiler

För att kunna ge kunder och andra intressenter möjlighet att uttrycka sina krav på säkerhet i IT-produkter används inom CC en konstruktion som kallas skyddsprofil (PP). Skyddsprofiler används för att beskriva säkerhetsbehov för grupper av IT-produkter, till exempel brandväggar. I motsats till ett säkerhetsmål, som bara kan användas för en specifik IT-produkt, kan skyddsprofiler användas för många typer av IT-produkter inom en och samma grupp.

I det följande beskrivs hur en skyddsprofil är uppbyggd och vad den måste innehålla:

Följande är exempel på hur en skyddsprofil kan användas:

• En kund eller grupp av kunder köper endast IT-produkter som är CC-certifierade enligt en viss skyddsprofil.
• En föreskrivande myndighet tillåter endast IT-produkter som är CC-certifierade enligt en viss skyddsprofil.
• En grupp utvecklare kommer överens om att de IT-produkter som de utvecklar minst ska klara en CC-certifiering mot en viss skyddsprofil.

Skyddsprofiler för låg assurans

I likhet med vad som gäller för säkerhetsmål för låg assurans behöver en skyddsprofil för låg assurans inte innehålla familjerna ASE_SPD Security Problem Definition och ASE_OBJ Security Objectives.