192 Guide för förenklad ST/PP

Transkript

1 Ärendetyp: 6 Diarienummer: 13FMV :113FMV :1 SP-192 Dokument ID: FMVID Swedish Certification Body for IT Security Issue: 3.0, Authorisation:Martin Bergling, Technical Manager Uncontrolled copy when printed

2 Table of Contents Swedish Certification Body for IT Security 1 Inledning Bakgrund Syfte Målgrupp Dokumentstruktur Terminologi Referenser 5 2 Struktur för en ST/PP enligt CC 6 3 Innehåll i en Förenklad ST / PP ST Introduction Conformance Claims Security Problem Definition Security Objectives Extended Components Definition Security Requirements TOE Summary Specification 14 4 Processbeskrivning 15 SP (16)

3 1 Inledning 1.1 Bakgrund Common Criteria (CC) är en internationell standard för att formulera krav på, samt evaluerar (utvärderar) säkerhet i IT-produkter i deras användningsmiljöer. Kraven definieras på ett standardiserat format i en produktsäkerhetsdeklaration (eng: Security Target - ST) eller i en skyddsprofil (eng: Protection Profile - PP), varefter produktens säkerhetsegenskaper evalueras mot dessa krav. Skyddsprofilen anger säkerhetsbehoven för en viss typ av produkt (t ex en viss typ av brandvägg) medan produktsäkerhetsdeklarationen anger säkerhetsbehoven för en specifik produkt (t ex en brandvägg från en specifik leverantör). CC fokuserar på det behov av IT- och informationssäkerhet som uppstår på grund av avsiktliga eller oavsiktliga hot utgående från krav på sekretess, riktighet och tillgänglighet. Att beskriva kraven på en produkt i en ST/PP i enlighet med Common Criteria förutsätter både hög expertis beträffande IT-säkerhet för den aktuella produkttypen och god kunskap om Common Criteria. I de fall en kravställare önskar använda Common Criteria för att definiera kraven på IT-säkerhet och senare genomföra en evaluering, är det värdefullt om kravställaren inledningsvis kan beskriva produktens önskade säkerhetsegenskaper utan att behöva vara expert på Common Criteria. Genom att skriva en förenklad kravställning enligt samma dokumentstruktur och modell som tillämpas i Common Criteria - men utan att tillämpa de mer detaljerade reglerna för hur krav på säkerhetsfunktioner och evaluering skall anges enligt CC - kan kravställare som inte är experter på CC ändå formulera sina krav i linje med standarden. En sådan förenklad ST/PP kan sedan utgöra en mycket god grund för senare arbeten att ta fram en ST/PP enligt CC, som motsvarar de formella kraven enligt Common Criteria och som tas fram i samverkan med CC-experter. 1.2 Syfte Syftet med denna guide är att möjliggöra framställning av en förenklad ST/PP för personer utan djup erfarenhet inom CC. Denna förenklade ST/PP kan sedan utgöra grund för framställning av en ST/PP enligt CC. 1.3 Målgrupp Målgruppen är personer som är insatta i IT- och informationssäkerhet - men inte är experter på Common Criteria - och som arbetar med kravställning av IT-säkerhet i produkter där målet är att produkterna skall CC-certifieras. 1.4 Dokumentstruktur Först presenteras den struktur som används vid kravställning av IT-säkerhet i produkter enligt Common Criteria (CC). Därefter ges en översiktlig beskrivning av innehållet i de avsnitt som skall ingå i en förenklad ST/PP. Centrala begrepp inom CC förklaras samt dess säkerhetsmodell, enligt vilken en översiktlig säkerhetsanalys leder fram till säkerhetsmålsättningar, vilka sedan uppfylls med detaljerade krav på säkerhetsfunktioner och granskning. Slutligen presenteras en rekommenderad process för framställning av förenklade ST/PP. SP (16)

4 1.5 Terminologi Då svenska uttryck och definitioner saknas för många centrala begrepp inom CC utgår denna ordlista från CC-terminologi (engelska), SIS HB-550 "SIS Handbok Terminologi för informationssäkerhet" (svenska) och CSEC-terminologi. I förekommande fall förtydligas engelska förklaringar även på svenska inom hakparanteser. Ord Adverse action Assets Assumptions Assurance Attack potential Augmentation Configuration Management (CM) Evaluation Evaluation Assurance Level (EAL) Flaw Remediation Organisational Security Policy (OSP), säkerhetspolicies Protection Profile (PP) Security Assurance Requirements (SARs) Security Functional Requirements (SFRs) Security Objective, säkerhetsmål, säkerhetsmålsättning Security Problem Definition Security Requirement Förklaring Attack; en fientlig handling utförd av en angripare mot en tillgång Entities that the owner of the TOE presumably places value upon. [objekt/information/resurser; tillgångar som skall skyddas]. Axiomatiska antaganden för miljön i vilken TOE skall användas. Dessa evlueras inte. Grounds for confidence that a TOE meets the SFRs. A measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise, resources and motivation. The addition of one or more requirement(s) to a package. [Att lägga till enskilda assuranskomponenter till en viss EAL-nivå]. Konfigurations- och ändringshantering som syftar till att garantera riktigheten hos TOE genom att alla förändringar sker på ett spårbart och kontrollerat sätt där man också kan se vem som godkänt förändringen och när. Assessment of a PP, an ST or a TOE, against defined criteria. An assurance package, consisting of assurance requirements drawn from CC Part 3, representing a point on the CC predefined assurance scale. [EAL 1-7, där 7 ger högst assurans - Man kan också välja en lägre nivå och lägga till enskilda komponenter (se augmentation)]. Detta innebär att utvecklaren har processer för att åtgärda fel i produkten, buggar, som upptäcks efter hand; samt informera kunderna om dessa och leverera rättningar, patchar. A set of security rules, procedures, or guidelines imposed (or presumed to be imposed) now and/or in the future by an actual or hypothetical organisation in the operational environment. [En tänkt regel från en organisation med rätt att ställa krav på den operativa miljön. Ställer säkerhetskrav utan att definiera hot och attacker (Threats)]. An implementation-independent statement of security needs for a TOE type. Assuranskrav; i CC definierade kravkomponenter som används för att evaluera TOE (granskningskrav; dvs. krav som ger en viss nivå av tillförlitlighet till säkerheten i produkten). Funktionella säkerhetskrav; i CC definierade kravkomponenter som används för att implementera säkerhetsmålsättningarna för TOE (Security Objectives for the TOE). A statement of intent to counter identified threats and/or satisfy identified organisation security policies and/or assumptions. [Här presenteras vad TOE och miljön behöver göra för att lösa problemen beskrivna i Security Problem Definition; hur Threats, OSP:er och Assumptions möts]. En hotbildsbeskrivning som definierar tillgångar, hot, policies och antaganden om miljön. Säkerhetskrav; i CC definierat funktionellt krav (SFR) eller granskningskrav (SAR). I avsnittet Security Requirements görs en fullständig mappning av SFR:er och SAR:ar mot säkerhetsmålsättningarna för TOE (Security Objectives for the TOE). SP (16)

5 Ord Security Target (ST) Target of Evaluation (TOE) Threat agent Threats, hot TOE Security Functionality (TSF) Förklaring An implementation-dependent statement of security needs for a specific identified TOE. A set of software, firmware and/or hardware possibly accompanied by guidance. Angripare; t.ex. en hacker, process, användare, administratör, utvecklare, olyckshändelse Möjlig oönskad händelse med negativa konsekvenser för verksamheten. Hot i CC kopplas alltid mot tillgångar som skall skyddas. Combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the SFRs [dvs. säkerhetsfunktionaliteten i TOE, definieras av SFR:erna] 1.6 Referenser De fyra första dokumenten (Common Criteria) finns att tillgå på Internet ( eller "ST/PP Guide" finns att beställa hos ISO och det sista dokumentet finns att tillgå genom kontakt med CSEC. Referens CC Part 1 CC Part 2 CC Part 3 CEM ST/PP Guide Security Target SSC-UNIX Beskrivning Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1 Revision 1, September 2006, CCMB Common Criteria for Information Technology Security Evaluation, Part 2: Security functional requirements, Version 3.1 Revision 2, September 2007, CCMB Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance requirements, Version 3.1 Revision 2, September 2007, CCMB Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 2, September 2007, CCMB Guide for the Production of Protection Profiles and Security Targets, ISO/IEC TR 15446:2009. Exempel-ST för en påhittad produkt: Simple Systems Company, SSC-UNIX. Den beskriver autenticering av användare och åtkomstkontroll för filer (på vanligt UNIX-manér). SP (16)

6 2 Struktur för en ST/PP enligt CC Den obligatoriska strukturen för ST/PP som uppfyller standardens krav framgår av bilderna nedan och skall tillämpas även för en förenklad ST/PP. De standardiserade huvudrubrikerna anges inramade i figuren nedan, och de likaledes standardiserade underrubrikerna anges enligt texten till höger om de inramade rubrikerna. I en förenklad ST/PP fokuseras på valda delar av denna struktur, vars innehåll och beskrivning av dessa återfinns i nästa kapitel. För en mer komplett beskrivning av struktur och innehåll i en ST/PP hänvisas till CC v3.1 del 1 Appendix A (ST) och Appendix B (PP). Det finns också en mer ingående ST/PP-Guide att tillgå (se referenslistan). Struktur för en Security Target SP (16)

7 Struktur för en Protection Profile SP (16)

8 3 Innehåll i en Förenklad ST / PP I föregående avsnitt visas strukturen för ST/PP i enlighet med standarden, vilken även gäller för den förenklade varianten. I detta avsnitt beskrivs innehållet för de delar som skall ingå i en förenklad ST/PP. 3.1 ST Introduction Avsnittet "ST Introduction", innehåller bl.a. sektionerna "TOE Overview" och "TOE Description", där "TOE Overview" är en mycket översiktlig beskrivning av vad TOE är för typ av produkt, dess huvudsakliga säkerhetsfunktioner och dess användningsområde. Viktigt att notera att begreppet säkerhetsfunktioner i TOE avser TSF vilket definieras av SFR:erna och inte säkerhetsfunktioner i någon vidare mening, t.ex. för ett större system. Sektionen "TOE Overview" skall innehålla följande information: Usage and major security features of the TOE Intended usage The essence of all security objectives for the operational environment D.v.s. allting man måste försäkra sig om är uppfyllt för miljön för att TOE skall vara säker evaluerad konfiguration beroenden av omgivningen, t.ex. specifika drivrutiner, operativsystem och plattformar Major security features Översiktlig beskrivning av säkerhetsfunktionerna i TOE (TSF) I sektionen "TOE Description" följer en mer detaljerad beskrivning av TOE och dess säkerhetsfunktioner. Här ingår delsektionen "TOE Scope" som ger en avgränsning mellan TOE och TOE Environment, dvs den miljö/omgivning i vilken TOE antas befinna sig. Syftet är att det skall vara entydigt vad som hör till TOE och vad som hör till miljön. Det är mycket viktigt att denna gränsdragning blir tydlig, eftersom den definierar vilka delar av en produkt som blir föremål för den kommande evalueringen (TOE - Target Of Evaluation) och vilka delar av produkten och dess omgivning som inte evalueras (TOE Environment). Delsektionen TOE Scope delas upp i: Physical Scope of the TOE: all hårdvara, mjukvara, firmware och dokumentation som utgör TOE Logical Scope of the TOE: Den funktionalitet som TOE erbjuder CEM efterfrågar här också en fullständig redogörelse för security features. Det är därför viktigt att lista även dessa (TSF). 3.2 Conformance Claims Detta avsnitt ingår ej i en förenklad ST/PP. 3.3 Security Problem Definition Avsnittet "Security Problem Definition" skall innehålla definitionen av säkerhetsproblemet, dvs en säkerhetsanalys där man tar fram: en hotbildsbeskrivning som visar vilka tillgångar (assets) man vill skydda alla hot (threats) mot dessa eventuella säkerhetspolicies (OSPs) som måste följas antaganden om miljön (assumptions) som TOE förväntas befinna sig i SP (16)

9 I sektionerna i detta avsnitt anges de hot (i sektionen "Threats"), säkerhetspolicies (i sektionen "Organisational Security Policies") samt antaganden (i sektionen "assumptions) som som bestämmer säkerhetsförutsättningarna för produkten. Hot, policies och antaganden brukar struktureras i listor i respektive sektion och ges unika namn ("taggar") enligt följande format: "T.<Tagnamn>" (för Threat), "OSP.<Tagnamn>" (för OSP) och "A.<Tagnamn>" (för Assumption); t.ex. A.NOEVIL, tillsammans med en text som beskriver respektive hot, policy eller antagande Threats I sektionen "Threats" listas de hot mot tillgångar som skall skyddas med hjälp av säkerhetsfunktioner i TOE, den operativa miljön eller en kombination av de båda. Hoten definieras genom att man associerar en angripare som utför en attack mot den eller de tillgångar som hotas. I sektionen beskrivs i lämplig form följande: Asset: tillgång som skall skyddas (objects/information/resources) Threat agent: angripare; t.ex. en hacker, process, användare, administratör, utvecklare, olyckshändelse Adverse action: attack; en (fientlig) handling utförd av en angripare mot en tillgång Man bör börja med att lista tillgångarna, sedan angriparna, och sist tillvägagångssätt för att därefter använda dessa när man definierar sina hot. Det är viktigt att allt detta definieras entydigt och konsistent. Begreppen behöver inte vara så värdeladdade som de låter på svenska. "A threat consists of an adverse action performed by a threat agent on an asset. Adverse actions are actions performed by a threat agent on an asset. These actions influence one or more properties of an asset from which that asset derives its value." [CC Part ] Organisational Security Policy I sektionen "Organisational Security Policy" definieras sådana säkerhetspolicies som ställer säkerhetskrav som TOE skall uppfylla, utan att bakomliggande hotbild och attackvägar anges (till skillnad mot vad som gäller för föregående sektion, "Threats"). Assets (och hotbild) bör ändå framgå på något sätt för att underlätta evaluering vad avser t.ex. bedömning av tillräcklighet i rationaler, hos vald EAL eller AVA_VANkomponent. OSP:er kan anges i ST/PP i de fall det finns axiomatiska säkerhetskrav som TOE måste uppfylla baserat på regler som etablerats inom en organisation. De kan även användas för att ange tvingande krav på TOE där en hotbildsanalys finns, men inte kan publiceras. Om det finns möjlighet att påverka OSP:er, försök undvik att formulera dessa som negativa krav Assumptions Sektionen "Assumptions" anger axiomatiska säkerhetsrelaterade antaganden för den omgivning/miljö i vilken TOE skall användas. Sådana antaganden bryts inte ned till säkerhetsfunktioner i TOE. De antaganden som listas i sektionen "Assumptions" innebär istället en slags friskrivning där man lägger krav på miljön istället för på TOE och där efterlevnaden av kraven därmed heller inte evalueras. Det är därför mycket viktigt att kraven på miljön (antagandena) faktiskt uppfylls för att produkten skall vara säker (dvs nå säkerhetsmålsättningarna, vilket beskrivs längre fram). SP (16)

10 Notera att i en ST/PP får sådana axiomatiska säkerhetsantaganden om TOE inte förekomma, utan de får bara anges för TOE Environment. Ett exempel på ett vanligt antagande är att administratörer i systemet är kompetenta, icke slarviga, pålitliga samt följer de instruktioner och den dokumentation som finns. Assumptions delas ofta upp i olika kategorier, t ex: Physical: t.ex. att TOE befinner sig i ett fysiskt skyddat utrymme Personnel: t.ex. att administratörerna inte utgör ett hot Connectivity: t.ex. att TOE inte kopplas till ett opålitligt nätverk 3.4 Security Objectives Baserat på beskrivningen i avsnittet "Security Problem Definition" anges i avsnittet "Security Objectives" säkerhetsmålsättningarna för TOE (i sektionen "TOE Security Objectives" och dess miljö (i sektionen "Security Objectives for the Operational Environment"). I dessa sektioner beskrivs de säkerhetsmålsättningar som är nödvändiga för att säkerhetsproblemet som beskrivs i det föregående avsnittet "Security Problem Definition" (hot, OSP:er och antaganden) skall kunna bemötas. Sektionen "Security Objectives" beskrivs på en hög nivå i naturligt språk utan specifika detaljer. Tänk på att försöka undvika negativa krav (se avsnittet "Security Requirements" i detta dokument) Security Objectives for the TOE I sektionen "Security Objectives for the TOE" bryts alla hot och OSP:er ned till säkerhetsmålsättningar som beskriver hur hoten skall bemötas, respektive hur OSP:er skall implementeras. Alla hot och OSP:er som angivits i tidigare avsnitt måste bemötas av de säkerhetsmålsättningar för TOE som anges här (tillsammans med säkerhetsmålsättningarna för miljön). Notera att antaganden om miljön inte skall bemötas av säkerhetsmålsättningar i denna sektion, då den bara hanterar säkerhetsmålsättningar för TOE, dvs Sektionen "Security Objectives for the TOE" måste (tillsammans med sektionen "Security Objectives for the Operational Environment") möta alla hot (i sektionen "Threats") och policies (i sektionen "Organizational Security Policies") Sektionen "Security Objectives for the TOE" skall inte möta de antaganden som anges i sektionen "Assumptions" Security Objectives for the Operational Environment Sektionen "Security Objectives for the Operational Environment" skall beskriva de säkerhetsmålsättningar som måste uppfyllas av miljön för att gjorda antaganden i sektionen "Assumptions" skall vara uppfyllda. Alla antaganden om miljön i tidigare sektion måste bemötas av säkerhetsmålsättningarna för miljön i denna sektion. Även hot och säkerhetspolicies som angivits i respektive sektion får bemötas av säkerhetsmålsättningar för miljön: Angivna säkerhetsmålsättningar i sektionen "Security Objectives for the Operational Environment" måste bemöta alla antaganden i sektionen "Assumptions" Angivna säkerhetsmålsättningar i sektionen "Security Objectives for the Operational Environment" får även bemöta hot och policies i sektionerna "Threats" och "Organisational Security Policies". SP (16)

11 3.4.3 Security Objectives Rationale I sektionen "Security Objectives Rationale" skall på ett tydligt sätt anges (t.ex. genom en tabell) vilka säkerhetsmålsättningar (Security Objectives) som möter vilka hot (i sektionen "Threats"), policies (i sektionen "Organisational Security Policies") och antaganden (i sektionen "Assumptions") för TOE respektive för miljö. Det är i en sådan tabell det är effektivt att ange de taggar för respektive hot, policy och antagande som beskrevs i tidigare avsnitt i detta dokument. Nedanstående citat ur CC Part 1 beskriver hur sektionen "Security Objectives Rationale" syftar till att på ett spårbart sätt visa att säkerhetsmålsättningarna på ett tillfredställande sätt bemöter de hot, OSP:er och antaganden som angivits i tidigare sektioner. "Based on the security objectives and the security objectives rationale, the following conclusion can be drawn: if all security objectives are achieved then the security problem as defined in the Security Problem Definition is solved: all threats are countered, all OSPs are enforced, and all assumptions are upheld" [CC Part 1 323]. 3.5 Extended Components Definition Detta avsnitt ingår ej i en förenklad ST/PP. 3.6 Security Requirements I avsnittet "Security Requirements" bryts säkerhetsmålsättningarna för TOE (angivna i sektionen "Security Objectives for the TOE"), ned till mer konkreta säkerhetskrav, som definierar exakt vilka tekniska säkerhetsfunktioner som skall implementeras i TOE (i sektionen "Security Functional Requirements") samt hur dessa skall granskas (i sektionen "Security Assurance Requirements") för att de angivna säkerhetsmålsättningarna för TOE skall uppnås. Om också säkerhetsmålsättningarna för miljön, baserat på de givna antagandena, uppfylls (detta granskas inte i CC) kan därmed behovet av säkerhet - som det definieras i definitionen av säkerhetsproblemet - antas vara tillfredställt: alla hot möts, alla säkerhetspolicies är uppfyllda och alla antaganden är upprätthållna. Negativa krav En mycket viktig princip i CC är att alltid försöka undvika att formulera negativa krav. Exempel på detta kan vara: "Det skall inte vara möjligt att "; dvs. krav som innebär att det inte skall vara möjligt att kringgå en viss säkerhetsfunktion. Man får problem då denna typ av krav tenderar till att bli mycket hårda (absoluta) och ofta är omöjliga att översätta till krav som faktiskt går att implementera som säkerhetsfunktioner. Sådana absoluta krav blir också ofta omöjliga att verifiera; hur kan man veta med 100% säkerhet att en viss säkerhetsfunktion inte går att kringgå - samt verifiera detta? Negativa krav i dessa sektioner bör därför, om möjligt, istället omformuleras som en mängd positiva krav: Sådant som går att implementera som säkerhetsfunktioner och som också går att verifiera. Detta gäller hela vägen från ev. OSP:er som anges i sektionen "Security Problem Definition", genom säkerhetsmålsättningarna för TOE (angivna i sektionen "Security Objectives for the TOE" till SFR:er i avsnittet "Security Requirements". Tillförlitligheten till att säkerhetsfunktionerna faktiskt fungerar (assuransen) styrs istället av omfattning och djup i granskningen (EAL och valda SAR:ar). Eventuella kvarstående sårbarheter är tänkta att upptäckas i sårbarhetsanalysen (penetrationstesterna). EAL och SAR:ar väljs bl.a. mot bakgrund av uppskattad attackpotential hos den tänkta angriparen. SP (16)

12 3.6.1 Security Functional Requirements I sektionen "Security Functional Requirements" bryts säkerhetsmålsättningarna för TOE (i sektionen "Security Objectives for the TOE"), ned till säkerhetskrav som på ett entydigt sätt definierar exakt vilka säkerhetsfunktioner som skall implementeras i TOE. För att kunna göra detta på ett enhetligt och standardiserat sätt definierar CC del 2 en samling kravkomponenter (Security Funcational Requirements - SFR:er) som har en speciell inbördes relation och som är definierade enligt CC:s konceptuella modell. Att göra ett korrekt urval av SFR:er som möter en adekvat och konsistent säkerhetsproblemsbeskrivning kräver ofta djup erfarenhet inom CC. I en förenklad ST/PP rekommenderas följande metod: Lista krav på säkerhetsfunktioner för TOE som är nödvändiga för att de säkerhetsmålsättningar som presenteras i sektionen "Security Objectives for the TOE" kan uppnås. Visa tydligt i en tabell hur dessa säkerhetsfunktioner gör att säkerhetsmålsättningarna uppnås (dvs. vilka funktioner som löser vilken eller vilka av målsättningarna). Gör kravlistan för säkerhetsfunktioner på ett godtyckligt sätt utan att nödvändigtvis använda CC:s fördefinierade SFR:er. Men utgå ifrån vedertagna IT- och informationssäkerhetstekniska begrepp som på ett tydligt sätt talar om vad som ska säkerställas och hur, t.ex: Autenticering (Authentication); Sekretess (Confidentiality); Riktighet (Integrity); Tillgänglighet (Availability); Spårbarhet, ansvarighet (Accountability); Oavvislighet (Non-repudiation); och Auktorisation (Authorisation). De SFR:er som definieras i CC del 2 kan vara till god hjälp för att få uppslag till vanliga förekommande säkerhetsfunktioner som kan vara behövliga Security Assurance Requirements I sektionen "Security Assurance Requirements" definieras kraven på assurans (tillförlitlighet), dvs. vilka granskningsåtgärder som skall vidtas för att säkerställa tillförlitligheten hos den säkerhetsfunktionalitet som anges i föregående sektion (Security Assurance Requirements - SAR:ar). För att en sådan granskning ska ske på ett enhetligt och standardiserat sätt innehåller CC del 3 en mängd olika SAR:ar. Exempel på granskningsområden är granskning av ST och PP; utvecklingsprocessen hos utvecklaren med arkitektur och design; installations- och användardokumentation; livscykelhantering med Change Management och Flaw Remediation; funktionella tester och sårbarhetsanalyser (penetrationstester). I en förenklad ST/PP räcker det att bestämma vilka angripare man vill skydda sig emot, och på ett godtyckligt sätt beskriva deras nivå av förmåga, vilka granskningsåtgärder man har tänkt sig och tänkt omfattning av dessa. Använd gärna de granskningsåtgärder som anges i CC del 3 som en utgångspunkt. Ett alternativ till att lista en serie granskningsåtgärder enligt ovan är att ange en s.k. EAL-nivå i enlighet med CC. En EAL-nivå utgör en samling av granskningsåtgärder valda ur CC del 3. Det finns sju nivåer (EAL 1-7), där genomförandet av granskningsåtgärder enligt respektive nivå ger en varierande nivå av tillförlitlighet till produkten, där EAL 1 leder till minst antal granskningsåtgärder och EAL 7 ger högst grad av tillförlitlighet till säkerhetsfunktionerna. I CC finns en definierad metod att räkna ut attackpotential som utgår ifrån följande faktorer: Tidsåtgång, expertis, kunskap om TOE, tillfälle och utrustning; och som ger följande nivåindelning: Grundläggande (basic), utökad grundläggande (extendedbasic), medel (moderate), hög (high) och över hög (beyond high). SP (16)

13 Det är svårt att komma med en rekommendation kring val av assuransnivå (EAL och SAR:ar) då detta måste bedömas utifrån en rad faktorer som t.ex. attackpotential hos tänkt angripare, värdet hos tillgångarna (assets) produkten skyddar, det skydd miljön ger (assumption och Security Objectives for the Environment) och aktuell budget. Men ett vanligt val är: EAL 3, eller EAL 4 + Flaw Remediation (en extra assuranskomponent som innebär att utvecklaren har en process för att rätta eventuella nyupptäckta fel och utfärda säkerhetspatchar för dessa). Kodgranskning, vilket kan ses som viktigt, ingår från EAL 4. Nedanstående tabell ger en sammanfattning av vilka granskningsåtgärder som genomförs inom respektive assuransnivå. För en mer komplett beskrivning hänvisas till kapitel 8 i CC del 3. De högre nivåerna ärver alltid av de lägre; omfattning och djup av granskning ökar, nya granskningskomponenter tillkommer och granskningsdjupet i existerande komponenter ökar. EAL 1 EAL 2 EAL 3 EAL 4 EAL 5 EAL 6 EAL 7 Assuransnivå (EAL) Beskrivning Produkt granskas som svart låda, testas endast via yttre gränssnitt. Granskning av manualer m.m. Utvecklaren knappt involverad. Skall möta angripare med "Basic Attack Potential". Inre struktur och arkitektur beaktas. Penetrationstest baserad på evaluerarens sårbarhetsanalys (designspec. m.m. beaktas). Krav på CM-system och en säker leverans av TOE. Skall möta angripare med "Basic Attack Potential". Granskning av utvecklarens skydd mot manipulation av TOE, mer utförlig granskning och testning. Skall möta angripare med "Basic Attack Potential". Granskning av design ned till kodnivå, granskning av kod. Automatisering av CM-system. Kontroll av utvecklingsverktyg. Skall möta angripare med "Enhanced- Basic Attack Potential". Krav på modulär design av säkerhetsfunktionerna och en mer strukturerad arkitektur. Strukturell granskning, semiformell designbeskrivning. Skall möta angripare med "Moderate Attack Potential". Formell modellering av säkerhetspolicies, semiformell designspec. Krav på strukturerad utvecklingsprocess och fullständigt automatiserat CM-system. Skall möta angripare med "High Attack Potential". Krav på formell representation, mycket utförlig testning och verifiering, och enkel design av säkerhetsfunktionaliteten. Strukturerad presentation av implementationen, koden. Skall möta angripare med "High Attack Potential" Security Requirements Rationale I sektionen "Security Requirements Rationale" listas krav på säkerhetsfunktioner för TOE som implementerar de säkerhetsmålsättningar som presenteras i sektionen "Security Objectives for the TOE". Kraven och säkerhetsmålsättningarna kopplas ihop på ett tydligt sätt och presenteras i en tabell. Nedanstående två citat från CC beskriver det konceptuella sammanhanget mellan SFR:er, SAR:ar, säkerhetsmål, säkerhetspolicies, antaganden, definition av säkerhetsproblem och säkerhetsmålsättning. Slutsatsen syftar till att visa att med de förutsättningar som anges i ST/PP:n så kan TOE uppnå de angivna säkerhetsmålsättningarna. SP (16)

14 Relations between the security problem definition, the security objectives and the security requirements. "All of the above can be combined into the statement: If all SFRs and SARs are satisfied and all security objectives for the operational environment are achieved, then there exists assurance that the security problem as defined in the Security Problem Definition is solved: all threats are countered, all OSPs are enforced, and all assumptions are upheld. This is illustrated in the figure below" [CC Part 1 345]. "The amount of assurance obtained is defined by the SARs, and whether this amount of assurance is sufficient is defined by the explanation for choosing these SARs" [CC Part 1 346]. 3.7 TOE Summary Specification Avsnittet "TOE Summary Specification" finns bara med i en ST (ej i en PP) och beskriver då konkret en specifik produkt. Det beskriver hur kraven på säkerhetsfunktioner, SFR:er, implementeras i TOE för denna produkt (generella tekniska mekanismer som beskriver detta); t.ex. huruvida autenticeringen (om krav finns på detta) implementeras genom lösenord, token, biometri eller certifikat. Här ska finnas en beskrivning av använda standarder, metoder och relevanta detaljer. SP (16)

15 4 Processbeskrivning För att kunna börja modellera en kravställning av IT-säkerhet i produkter utan ingående erfarenhet inom Common Criteria kan följande process tillämpas: utifrån en ungefärlig uppskattning kring vad som är TOE, listas och beskrivs tillgångar (Assets), möjliga angripare (Threat agents) mot dessa tillgångar och vilka typer av attacker (Adverse actions) dessa angripare kan utföra mot tillgångarna. Beskrivningen av tillgångarna är betydelsefullt för den kommande detaljnivån på övriga ST:n, det gäller att hitta en lagom nivå. Tänk på att alltid försöka undvika negativa krav (se Security Requirements). 1. Gör en preliminär uppskattning av vad TOE skall omfatta (och därmed vad som skall evalueras) respektive vad som skall antas ingå i miljön (och inte skall evalueras) i undersektion "TOE Scope", i sektionen "TOE Description" i Avsnittet "ST Introduction". 2. Definiera tillgångarna som skall skyddas i sektionen "Threats" i avsnittet "Security Problem Definition". 3. Definiera möjliga angripare mot tillgångarna i sektionen "Threats" i avsnittet "Security Problem Definition". 4. Definiera vilka typer av attacker angriparna kan utföra mot tillgångarna i sektionen "Threats" i avsnittet "Security Problem Definition". 5. Sammanställ en mappning mellan angripare, typ av attack och tillgång i sektionen "Threats" i avsnittet "Security Problem Definition". 6. Lista ev. OSP:er i sektionen "Organisational Security Policies" i avsnittet "Security Problem Definition". Dessa kan ses som krav på TOE för att möta hot som inte redovisas i riskanalysen i sektionen "Threats". 7. Lista säkerhetsrelaterade antaganden om miljön som möter vissa av hoten (istället för att dessa hot bemöts via skyddsfunktioner i TOE) i sektionen "Assumptions" i avsnittet "Security Problem Definition". 8. Gör nu en noggrann analys av vad som är TOE och vad som är miljö och definiera "TOE Scope". 9. Definiera i sektionen "Security Objectives for the Operational Environment" i avsnittet "Security Objectives" vilka hot som skall mötas av miljön (och därigenom inte evalueras), samt i sektionen "Security Objectives for the TOE" vilka hot som skall mötas av väldefinierade säkerhetsfunktioner i TOE (som därmed evalueras). 10. Knyt ihop hot, OSP:er och antaganden mot Security Objectives för TOE respektive för miljön. Presentera detta på ett tydligt sätt genom en tabell i sektionen "Security Objectives Rationale" i avsnittet "Security Objectives". 11. Lista krav på säkerhetsfunktioner för TOE som gör att de säkerhetsmålsättningar som presenteras i sektionen "Security Objectives for the TOE" kan uppnås, koppla ihop dessa krav med säkerhetsmålsättningarna, och presentera detta tydligt i en tabell. Gör kravlistan för säkerhetsfunktioner på ett godtyckligt sätt utan att nödvändigtvis ordagrant använda CC:s fördefinierade SFR:er. Men utgå ifrån vedertagna IT- och informationssäkerhetstekniska begrepp som på ett tydligt sätt talar om vad som ska säkerställas och hur, t.ex: Autenticering (Authentication); Sekretess (Confidentiality); Riktighet (Integrity); Tillgänglighet (Availability); Spårbarhet, ansvarighet (Accountability); Oavvislighet (Non-repudiation); och Auktorisation (Authorisation). De SFR:er som definieras i CC del 2 kan vara till god hjälp för att få uppslag till vanliga förekommande säkerhetsfunktioner som kan vara behövliga. SP (16)

16 12. Bestäm krav på assurans genom att bedöma vilken attackpotential den tänkta angriparen har och välj EAL-nivå efter detta (enstaka assuranskomponenter kan också läggas till). Detta sätter granskningskraven efter önskad nivå av tillförlitlighet genom att definiera såväl omfattning som djup av granskningsåtgärderna. Är man osäker på vad som skiljer mellan de olika EALnivåerna och SAR:arna kan man börja med att bestämma vilka angripare man vill skydda sig emot, och på ett godtyckligt sätt beskriva vilka granskningsåtgärder man har tänkt sig och tänkt omfattning av dessa. 13. Koppla ihop säkerhetskraven med säkerhetsmålsättningarna och presentera detta på ett tydligt sätt genom en tabell i sektionen "Security Requirements Rationale" i avsnittet "Security Requirements". 14. För en ST, ej för en PP: Beskriv hur kraven på säkerhetsfunktioner, SFR:er, implementeras i TOE (generella tekniska mekanismer som beskriver detta); t.ex. huruvida autenticeringen (om krav finns på detta) implementeras genom lösenord, token, biometri eller certifikat. Beskriver använda standarder, metoder och relevanta detaljer. SP (16)