192 Guide för förenklad ST/PP

Storlek: px
Starta visningen från sidan:

Download "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 (www.csec.se 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)

Vad är speciellt med IT-säkerhet?

Vad är speciellt med IT-säkerhet? Assurans Ett mått på tillit till IT-säkerhet i produkter och system Dag Ströman, Mats Ohlin Bonniers: Skydd, Trygghet Websters: Freedom from threats Begreppet säkerhet Behovet av en standard för säkerhet

Läs mer

Agenda SWEDISH CERTIFICATION BODY FOR IT SECURITY

Agenda SWEDISH CERTIFICATION BODY FOR IT SECURITY Assurans Ett mått på tillit till IT-säkerhet i produkter och system Dag Ströman, Mats Ohlin Agenda Begreppet säkerhet Behovet av en standard för säkerhet i IT-produkter Common Criteria En introduktion

Läs mer

Agenda. Kort om CC. Utvecklingen nu och framöver. Hur använda CC vid upphandling? CSEC roll CCRA. Internationellt Sverige. Konkurrens på lika villkor

Agenda. Kort om CC. Utvecklingen nu och framöver. Hur använda CC vid upphandling? CSEC roll CCRA. Internationellt Sverige. Konkurrens på lika villkor - Kravställning på IT-säkerhetsprodukter Försvarets Materielverk/CSEC 2005 Document ID Issue 0.1 Cybersäkerhet SESAM 2012-05-10 Dag Ströman Verksamhetschef FMV/CSEC 1 Agenda Kort om CC CSEC roll CCRA Utvecklingen

Läs mer

Common Criteria Certification of Open Source Software

Common Criteria Certification of Open Source Software Certification of Open Source Software Tomas Gustavsson PrimeKey Solutions AB www.ejbca.org www.cesecore.eu Agenda Common Criteria Vad Varför Open Source Hur fungerar de ihop? Hur påverkas ett projekt?

Läs mer

Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB

Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB Riskhantering för informationssäkerhet med ISO 27005 Lars Söderlund, TK 318 Ag 7 Lüning Consulting AB Varför ISO/IEC 27005 Information Security Management?? Riskanalys och riskhantering är centrala aktiviteter

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

ISO/IEC 20000, marknaden och framtiden

ISO/IEC 20000, marknaden och framtiden ISO/IEC 20000, marknaden och framtiden Frukostseminarium 2009-10-05 Anita Myrberg BiTA Service Management anita.myrberg@bita.eu Agenda ISO/IEC 20000 Vad, varför, hur börja? Relation till andra standarder

Läs mer

Implementationsstrategier för PLCS

Implementationsstrategier för PLCS Implementationsstrategier för PLCS Dr Mattias Johansson Director Software Products Eurostep AB Typically complex systems environment Point to Point Integration Operational Objectives CM CM CM CM 5. Requirements

Läs mer

REGELVERK & HANDBÖCKER

REGELVERK & HANDBÖCKER 1 (5) REGELVERK & HANDBÖCKER Innehåll sid. Uppdateringar/kompletteringar 2 Nyskrivning av rutiner 4 Gränsytan mellan systemsäkerhet och programvarusäkerhet 5 2 (5) Uppdateringar/kompletteringar Software

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Revisionsrapport IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Landstinget i Jönköpings län Kerem Kocaer Johan Elmerhag Jean Odgaard September 2013 Innehållsförteckning

Läs mer

SWAMID. Nyttjandestatistik av SWAMID. Vad är SWAMID? Så, hur mycket används SWAMID idag? Vi vet inte.. http://flog.sunet.se en första demonstration!

SWAMID. Nyttjandestatistik av SWAMID. Vad är SWAMID? Så, hur mycket används SWAMID idag? Vi vet inte.. http://flog.sunet.se en första demonstration! Nyttjandestatistik av SWAMID SWAMID och Ladok 3 SWAMIDs vikt för SUNET och oss som lärosäten Nästa SWAMID WS 15-16 Maj i Stockholm Formell AL1 (LoA1) - profil på remiss Internationella samarbeten edugain!

Läs mer

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser

IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Revisionsrapport IT-säkerhet Externt och internt intrångstest samt granskning av IT-säkerhetsprocesser Landstinget i Östergötland Kerem Kocaer Magnus Olson-Sjölander Björn Johrén IT-specialister Eva Andlert

Läs mer

Testning som beslutsstöd

Testning som beslutsstöd Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten

Läs mer

Utredning av central teknisk lösning för att upptäcka avvikelser och potentiella hot i landstingets nätverk och kritiska IT-system

Utredning av central teknisk lösning för att upptäcka avvikelser och potentiella hot i landstingets nätverk och kritiska IT-system Stockholms läns landsting Landstingsstyrelsens förvaltning SLL Informationssäkerhet SLL IT Handläggare: Vesna Lucassi Landstingsstyrelsens innovationsberedning Ankom Stockholms läns landsting 2015-08-

Läs mer

IT-säkerhet Externt och internt intrångstest

IT-säkerhet Externt och internt intrångstest Revisionsrapport IT-säkerhet Externt och internt intrångstest Region Halland Kerem Kocaer December 2012 Innehållsförteckning Inledning... 3 Bakgrund... 3 Revisionsfråga... 3 Angreppssätt... 4 Syfte och

Läs mer

Riskanalys och informationssäkerhet 7,5 hp

Riskanalys och informationssäkerhet 7,5 hp Riskanalys och informationssäkerhet 7,5 hp Margaretha Eriksson Civ.Ing. och doktorand i informationssäkerhet KTH irbiskonsult@tele2.se Föreläsning 1 Vad menar vi med säkerhet? Säkerhet är en grad av skydd

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Designprinciper för säkerhet och Epilog. Marcus Bendtsen Institutionen för Datavetenskap (IDA) Avdelningen för Databas- och Informationsteknik (ADIT)

Designprinciper för säkerhet och Epilog. Marcus Bendtsen Institutionen för Datavetenskap (IDA) Avdelningen för Databas- och Informationsteknik (ADIT) Designprinciper för säkerhet och Epilog Marcus Bendtsen Institutionen för Datavetenskap (IDA) Avdelningen för Databas- och Informationsteknik (ADIT) Designprinciper för säkerhet Tumregler och utgångspunkter

Läs mer

FÖRHINDRA DATORINTRÅNG!

FÖRHINDRA DATORINTRÅNG! FÖRHINDRA DATORINTRÅNG! Vad innebär dessa frågeställningar: Hur görs datorintrång idag Demonstration av datorintrång Erfarenheter från sårbarhetsanalyser och intrångstester Tolkning av rapporter från analyser

Läs mer

Kompetens på Certifying Staff i POA? Checklista vid release med FORM 1?

Kompetens på Certifying Staff i POA? Checklista vid release med FORM 1? Certifying Staff Frågor från myndigheten som vi vill FÖRTYDLIGA: Kompetens på Certifying Staff i POA? Checklista vid release med FORM 1? 1 Fundera över. Vilken nivå på teknisk kompetens krävs på Certifying

Läs mer

Molnet eller outsourcing??

Molnet eller outsourcing?? Molnet eller outsourcing?? Vilka är vi? Lars Söderlund UPPSEC AB Ordförande SIS TK 318 AG 11 www.uppsec.se lars.soderlund@uppsec.se Jan Branzell Veriscan Security AB Ordförande SIS TK 318 AG 41 www.versican.se

Läs mer

Metodbeskrivning för framtagning av. Användningsfall. Användningsfall

Metodbeskrivning för framtagning av. Användningsfall. Användningsfall Metodbeskrivning för framtagning av Användningsfall Användningsfall 2014-05-30 13FMV5921-8:2 Härmed fastställs Leverans av ISD version 2.0 för delgivning till Försvarsmakten Högkvarteret till LedS CIO

Läs mer

Process 8 Skyddsstrategi

Process 8 Skyddsstrategi Process 8 Skyddsstrategi Planera för Fas 1: Organisatorisk bild Fas 2: Teknisk bild Fas 3: Riskanalys Process 1: Kunskapsinsamling - chefsnivå Process 5: Identifiera nyckelkomponenter Process 7: Utför

Läs mer

Intrångstester SIG Security, 28 oktober 2014

Intrångstester SIG Security, 28 oktober 2014 Intrångstester SIG Security, 28 oktober 2014 Mattias Berglund Oberoende konsult inom IT- och informationssäkerhetsområdet Fokus på test och granskningar av system Bakgrund inom drift och förvaltning, säkerhetskonsult

Läs mer

ISD - IT-säkerhetsdeklaration. Information till SESAME Dan Olofsson PrL ISD 070-6825904

ISD - IT-säkerhetsdeklaration. Information till SESAME Dan Olofsson PrL ISD 070-6825904 ISD - IT-säkerhetsdeklaration Information till SESAME Dan Olofsson PrL ISD 070-6825904 Agenda Varför ISD? Omfattning ISD, Informationssäkerhet kontra IT-säkerhet Status Vad är ISD? Varför ISD? Projekt

Läs mer

FMV Instruktion för verifiering system av system på nivå 4. System av system på nivå 4

FMV Instruktion för verifiering system av system på nivå 4. System av system på nivå 4 FMV Instruktion för verifiering system av system på nivå 4 System av system på nivå 4 2013-06-18 13FMV5921-8:1 Härmed fastställs Leverans av ISD version 2.0 för delgivning till Försvarsmakten Högkvarteret

Läs mer

Riktlinjer för IT-säkerhet i Halmstads kommun

Riktlinjer för IT-säkerhet i Halmstads kommun Riktlinjer för IT-säkerhet i Halmstads kommun VER 1.0 Innehåll Inledning...3 Definition av IT-säkerhet...3 Omfattning...3 Vikten av IT-säkerhet...3 Mål för IT-säkerhetsarbetet...4 Ledning och ansvar...4

Läs mer

Tillitsramverk och Kantara Revision enligt Kantara IAF

Tillitsramverk och Kantara Revision enligt Kantara IAF Tillitsramverk och Kantara Revision enligt Kantara IAF Björn Sjöholm Europoint Networking bear@europoint.se 0705-220110 2012-11-14 1 Björn Sjöholm Konsult på Europoint specialiserad inom: Informationssäkerhet

Läs mer

ISD. Etablering av ISD inom FMV. Dan Olofsson PrL ISD 070-6825904

ISD. Etablering av ISD inom FMV. Dan Olofsson PrL ISD 070-6825904 ISD Etablering av ISD inom FMV Dan Olofsson PrL ISD 070-6825904 Definition Informationssäkerhet Informationssäkerhet Administrativ säkerhet Teknisk säkerhet Policy Rutiner etc Fysisk säkerhet IT-säkerhet

Läs mer

Beijer Electronics AB 2000, MA00336A, 2000-12

Beijer Electronics AB 2000, MA00336A, 2000-12 Demonstration driver English Svenska Beijer Electronics AB 2000, MA00336A, 2000-12 Beijer Electronics AB reserves the right to change information in this manual without prior notice. All examples in this

Läs mer

Informationssäkerhet och medicintekniska produkter eller Information security with respect to safety considerations

Informationssäkerhet och medicintekniska produkter eller Information security with respect to safety considerations Informationssäkerhet och medicintekniska produkter eller Information security with respect to safety considerations Mats Ohlson Informationssäkerhet = Information security Informationssäkerhet the preservation

Läs mer

Analyser. Verktyg för att avgöra vilka skydd som behövs

Analyser. Verktyg för att avgöra vilka skydd som behövs Analyser Verktyg för att avgöra vilka skydd som behövs Analystyper Sårbarhetsanalys Svarar på frågan Hur viktigt är det att jag bryr mig Hotanalys Svarar på frågan Hur utsatt är just jag för kända, tänkbara

Läs mer

Hur gör man en ansökan till Horisont 2020 11 december 2013 Jenny Holgersson, Red Energy Experts AB Clas Tegerstrand, Sustainable Business Mälardalen

Hur gör man en ansökan till Horisont 2020 11 december 2013 Jenny Holgersson, Red Energy Experts AB Clas Tegerstrand, Sustainable Business Mälardalen Hur gör man en ansökan till Horisont 2020 11 december 2013 Jenny Holgersson, Red Energy Experts AB Clas Tegerstrand, Sustainable Business Mälardalen Steg 1 hitta utlysningen! Dokument som följer med utlysningen

Läs mer

Styrelsens för ackreditering och teknisk kontroll författningssamling

Styrelsens för ackreditering och teknisk kontroll författningssamling Styrelsens för ackreditering och teknisk kontroll författningssamling ISSN 1400-4682 Utgivare: Gerda Lind STAFS 2013:xx Utkom från trycket den xx månad 20XX Föreskrifter om ändring i Styrelsens för ackreditering

Läs mer

RIKTLINJE Sida 1 (5) KOMMUN. Datum

RIKTLINJE Sida 1 (5) KOMMUN. Datum Bilaga 3 Kommunstyrelsen 2017-01-16 13 STORFORS RIKTLINJE Sida 1 (5) Datum Diarienummer 2016-12-12 Fastställt av Klicka här för att ange text. Dokumentansvarig Processtödjare Riktlinjer för dokument i

Läs mer

Bygg bro mellan ITIL v2 och v3 - Bridgekurser - DF Seminarium 2008-09-05

Bygg bro mellan ITIL v2 och v3 - Bridgekurser - DF Seminarium 2008-09-05 Bygg bro mellan ITIL v2 och v3 - Bridgekurser - DF Seminarium 2008-09-05 Innehåll Kursöversikt ITIL v3 Utbildningsschemat Målgrupper & förkunskapskrav Kursuppbyggnad & innehåll V2 V3, Service Lifecycle,

Läs mer

Internt penetrationstest. Tierps kommun. Revisionsrapport. Juni 2011. Erik Norman 1(6)

Internt penetrationstest. Tierps kommun. Revisionsrapport. Juni 2011. Erik Norman 1(6) Internt penetrationstest Tierps kommun Revisionsrapport Juni 2011 Erik Norman 1(6) Innehållsförteckning 1. Sammanfattning... 3 1.1. Bakgrund... 3 1.2. Revisionsfråga... 3 2. Angreppssätt... 4 2.1. Omfattning

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst.

Läs mer

Varför ska vi ha en informationssäkerhetspolicy och hur tar vi fram en? En policy ska ju fånga in en organisations målsättning för ett visst område,

Varför ska vi ha en informationssäkerhetspolicy och hur tar vi fram en? En policy ska ju fånga in en organisations målsättning för ett visst område, Varför ska vi ha en informationssäkerhetspolicy och hur tar vi fram en? En policy ska ju fånga in en organisations målsättning för ett visst område, det må vara personal, miljö, eller informationssäkerhet.

Läs mer

Att fatta rätt beslut vid komplexa tekniska upphandlingar

Att fatta rätt beslut vid komplexa tekniska upphandlingar Att fatta rätt beslut vid komplexa tekniska upphandlingar Upphandlingsdagarna 2015 Stockholm 29 januari 2015 1 Inledning Den här presentation kommer att undersöka de vanligaste fallgroparna vid komplex

Läs mer

Terminologi inom informationssäkerhetsområdet HB 550 har blivit TR-50

Terminologi inom informationssäkerhetsområdet HB 550 har blivit TR-50 Terminologi inom informationssäkerhetsområdet HB 550 har blivit TR-50 TK 318 2015-09-02 Jan-Olof Andersson Bearbetat underlag från: Lars Söderlund/Rose-Mharie Åhlfeldt 2015-09-07 1 TR-50 Teknisk rapport

Läs mer

Gränssnitt och identiteter. - strategiska frågor inom Ladok3

Gränssnitt och identiteter. - strategiska frågor inom Ladok3 - strategiska frågor inom Ladok3 Sida 2 av 9 er Revision Datum Av Kommentar Granskare Godkännare 0.1 2011-05-26 Daniel Lind Utkast 0.2 2011-05-30 Daniel Lind Synpunkter från Catherine 0.3 2011-06-16 Daniel

Läs mer

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0 Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0 Innehåll Revisionshistorik... 2 1. Inledning... 2 1.1. Syfte... 2 1.2. Omfattning och avgränsning... 2 2. Princip

Läs mer

INFORMATIONSTEKNISK ARKITEKTUR OCH INFRASTRUKTUR

INFORMATIONSTEKNISK ARKITEKTUR OCH INFRASTRUKTUR INFORMATIONSTEKNISK ARKITEKTUR OCH INFRASTRUKTUR Ämnet informationsteknisk arkitektur och infrastruktur behandlar de grundläggande processerna, komponenterna och gränssnitten i ett sammanhängande informationstekniskt

Läs mer

Rätt säkerhet Outsourcing

Rätt säkerhet Outsourcing Rätt säkerhet 2015-05-27 - Outsourcing Plan del 1 27036-Outsourcing Varför finns standarden Vad karaktäriserar outsourcing och leverantörsrelationer? Struktur på standarden Skillnader del 2/3/4 Hur kan

Läs mer

Exempel på verklig kravspecifikation

Exempel på verklig kravspecifikation Exempel på verklig kravspecifikation Detta är ett exempel på en proffessionell kravspecifikation hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och

Läs mer

RIKTLINJER FÖR STYRDOKUMENT

RIKTLINJER FÖR STYRDOKUMENT RIKTLINJER FÖR STYRDOKUMENT Fastställt av: Kommunfullmäktige Datum: 2012-06-19, 81 För revidering ansvarar: Kommunstyrelsen För eventuell uppföljning och tidplan ansvarar: - Dokumentet gäller för: Alla

Läs mer

Mars 2012. Vägledning för informations säkerhetsdeklarationen. Säkerhet vid anskaffning och utvecking av system

Mars 2012. Vägledning för informations säkerhetsdeklarationen. Säkerhet vid anskaffning och utvecking av system Mars 2012 Vägledning för informations säkerhetsdeklarationen Säkerhet vid anskaffning och utvecking av system Vägledning för informationssäkerhetsdeklarationen Ett forskningsprojekt i samverkan mellan

Läs mer

Riktlinjer för styrdokument

Riktlinjer för styrdokument Riktlinjer för styrdokument Fastställt av: Kommunfullmäktige Datum: 2014-12-15, 135 Diarienummer: 2014-000378 För revidering ansvarar: Kommunchef För eventuell uppföljning och tidplan ansvarar: Kommunchef

Läs mer

UML use cases. Mikael Söderström Institutionen för informatik Umeå universitet micke@informatik.umu.se

UML use cases. Mikael Söderström Institutionen för informatik Umeå universitet micke@informatik.umu.se UML use cases micke@informatik.umu.se Use case (användningsfall) En modelleringsteknik som hjälper utvecklare att bestämma vilka funktioner som ska implementeras i ett system/applikation Finns olika typer

Läs mer

Validering synliggör det informella lärandet

Validering synliggör det informella lärandet Validering synliggör det informella lärandet Hur länkar man ihop validering med SeQF på ett relevant och effektivt sätt? SeQF-konferens 11 november 2015 Det informella lärandets karaktär Ett stort antal

Läs mer

Bilaga 3 Säkerhet Dnr: /

Bilaga 3 Säkerhet Dnr: / stockholm.se Utbildningsförvaltningen Avdelningen för utveckling och samordning Hantverkargatan 2F 104 22 Stockholm Växel 08-508 33 000 www.stockholm.se Innehåll 1 Inledning 3 2 Krav på säkerhetsarbete

Läs mer

Styr och utveckla ditt IT-stöd utifrån internationella standarder

Styr och utveckla ditt IT-stöd utifrån internationella standarder Styr och utveckla ditt IT-stöd utifrån internationella standarder Frukostseminarium 2008-09-19 Anita Myrberg BiTA Service Management Agenda ISO/IEC 20000 Relation till andra standarder Varför styra en

Läs mer

Konsoliderad version av

Konsoliderad version av Konsoliderad version av Styrelsens för ackreditering och teknisk kontroll (SWEDAC) föreskrifter och allmänna råd (STAFS 2007:12) om ackreditering av organ som certifierar produkter Ändring införd: t.o.m.

Läs mer

Att beskriva förband för nationell och multinationell insats. Michael Stolz Produktledare FMV SPL SP

Att beskriva förband för nationell och multinationell insats. Michael Stolz Produktledare FMV SPL SP Att beskriva förband för nationell och multinationell insats Michael Stolz Produktledare FMV SPL SP Disclaimer / Friskrivning This presentation represents opinions of the author, which does not necessarily

Läs mer

Optimering av licenshantering Hur arbetar FMV? Björn Spåra Crayon AB

Optimering av licenshantering Hur arbetar FMV? Björn Spåra Crayon AB Optimering av licenshantering Hur arbetar FMV? Björn Spåra 2008 01 29 2 Bakgrund 3 SAM arbete 4 SAM arbete 5 SAM arbete 6 SAM arbete Genom ett outsourcingavtal mellan FMV och WM-data fick Crayon, som SAM

Läs mer

Genomförande av SSP och SMS i Sverige. Hur ökar vi flygsäkerheten bortom regelverket? Hur balanserar vi mellan produktion och säkerhet?

Genomförande av SSP och SMS i Sverige. Hur ökar vi flygsäkerheten bortom regelverket? Hur balanserar vi mellan produktion och säkerhet? Genomförande av SSP och SMS i Sverige Hur ökar vi flygsäkerheten bortom regelverket? Hur balanserar vi mellan produktion och säkerhet? Vi börjar med SSP State Safety Programme Varje ICAO-stat ska ha ett

Läs mer

Intro utvärdering

Intro utvärdering Föreläsning 2: Introduktion till varför ska vi utvärdera? FSR: 1, 2, 5 Rogers et al. Kapitel 13 (e/3: 12-13) 2 Översikt Att kunna om Observation, kort repetition Iterativ Det som påverkar Tänkbara syften

Läs mer

GJUTEN ALUMINIUMPLATTA EN AW 5083 CAST ALUMINIUM PLATE EN AW 5083

GJUTEN ALUMINIUMPLATTA EN AW 5083 CAST ALUMINIUM PLATE EN AW 5083 GJUTEN ALUMINIUMPLATTA EN AW 5083 CAST ALUMINIUM PLATE EN AW 5083 Granskad av Reviewed by Göran Magnusson Tjst Dept. GUM1 tb tvåspråkig 2008-06-17 1 (9) ÄNDRINGSFöRTECKNING RECORD OF CHANGES Ändring nummer

Läs mer

Informationssäkerhet - en översikt. Louise Yngström, DSV

Informationssäkerhet - en översikt. Louise Yngström, DSV Informationssäkerhet - en översikt Louise Yngström, DSV Närmaste 50 minuterna... Informationssäkerhet? Definition Mål Krav Medel Datasäkerhet säkerhet beträffande skydd av datorsystem och dess data syftande

Läs mer

Har funnits nästan lika länge som datorerna. Manuell process, svarta tavlan Verktygsstöd kom tidigt redan i början på

Har funnits nästan lika länge som datorerna. Manuell process, svarta tavlan Verktygsstöd kom tidigt redan i början på Versionshantering och subversion Bara en liten ändring till Vad är versionshantering? Versionshantering låter dig arbeta med olika versioner av systemet Versionshantering är en säkerhetsmekanism som tillåter

Läs mer

GTP Info KP 081113. P-O Risberg per-ola.risberg@logica.com. Jaan Haabma Jaan.haabma@basesoft.se. 2008-11-13 GTP Info KP Inforum 1

GTP Info KP 081113. P-O Risberg per-ola.risberg@logica.com. Jaan Haabma Jaan.haabma@basesoft.se. 2008-11-13 GTP Info KP Inforum 1 GTP Info KP 081113 Jaan Haabma Jaan.haabma@basesoft.se P-O Risberg per-ola.risberg@logica.com 2008-11-13 GTP Info KP Inforum 1 GTP - FM Generell Teknisk Plattform En IT-infrastruktur som bl a tillhandahåller

Läs mer

Sectra Critical Security Services. Fel bild

Sectra Critical Security Services. Fel bild Sectra Critical Security Services Fel bild Sectra is world leading in data security Sectra is also one of Europes most reknown IT-security companies with solutions such as: EU TOP SECRET High speed encryption

Läs mer

Programvara i säkerhetskritiska tillämpningar

Programvara i säkerhetskritiska tillämpningar Programvara i säkerhetskritiska tillämpningar Programvara får inte bidra till att person, egendom eller miljö skadas 2003-09-02 1 Systemsäkerhetsprocessen vid försvarsmakten materielupphandling beskrivs

Läs mer

TS revision. Lars Ekman

TS revision. Lars Ekman TS revision Lars Ekman TS-revision i Sverige efter EU direktiv eller ISO 39001 TS-revision i Sverige efter EU direktiv och ISO 39001 2 2011 05 14 Vägsäkerhetslag (2010:1362) Vägsäkerhetsförordning (2010:1367)

Läs mer

Metodbeskrivning för genomförande av Oberoende värdering i ISD-processens faser Produktion och Leverans till FM. Oberoende värdering i ISD-processen

Metodbeskrivning för genomförande av Oberoende värdering i ISD-processens faser Produktion och Leverans till FM. Oberoende värdering i ISD-processen Metodbeskrivning för genomförande av Oberoende värdering i ISD-processens faser Produktion och Leverans till FM Oberoende värdering i ISD-processen 2014-05-30 13FMV5921-11:3 Härmed fastställs Leverans

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR Kontrollera vilka kurser du vill söka under utbytet. Fyll i Basis for nomination for exchange studies i samråd med din lärare. För att läraren ska kunna göra en korrekt

Läs mer

Arbetstillfällen 100 000.

Arbetstillfällen 100 000. 2 3 4 Arbetstillfällen 100 000. 5 6 7 Vissa anspråk ställs I de internationella direktiv och konventioner Sverige antingen är ålagt att följa eller frivilligt valt att följa. Här har jag listat några exempel

Läs mer

ISO/IEC och Nyheter

ISO/IEC och Nyheter ISO/IEC 27001 och 27002 Nyheter Bakgrund till revisionen ISO/IEC 27001 och 27002 var cirka 10 år gamla och behövde uppdateras Harmonisering av ledningssystem (Annex SL) ISO/IEC 27001:2013(2014) ISO/IEC

Läs mer

Make a speech. How to make the perfect speech. söndag 6 oktober 13

Make a speech. How to make the perfect speech. söndag 6 oktober 13 Make a speech How to make the perfect speech FOPPA FOPPA Finding FOPPA Finding Organizing FOPPA Finding Organizing Phrasing FOPPA Finding Organizing Phrasing Preparing FOPPA Finding Organizing Phrasing

Läs mer

Angeppssätt för integration - standarder, internationell utblick och SIS

Angeppssätt för integration - standarder, internationell utblick och SIS Angeppssätt för integration - standarder, internationell utblick och SIS 9 november 2004 Sara Ellström 2004-11-17 1 Översikt 1 Vilka standarder kan stötta ett integrerat ledningssystem och hur kan standarderna

Läs mer

Regressionstestning teori och praktik

Regressionstestning teori och praktik Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification

Läs mer

BILAGA 3 Tillitsramverk Version: 1.3

BILAGA 3 Tillitsramverk Version: 1.3 BILAGA 3 Tillitsramverk Version: 1.3 Innehåll Allmänt... 2 A. Generella krav... 2 Övergripande krav på verksamheten... 2 Säkerhetsarbete... 3 Granskning och uppföljning... 3 Kryptografisk säkerhet... 3

Läs mer

Remissvar till Ju2015/2650/SSK, betänkandet SOU 2015:23 Informations- och cybersäkerhet i Sverige Strategi och åtgärder för säker information i staten

Remissvar till Ju2015/2650/SSK, betänkandet SOU 2015:23 Informations- och cybersäkerhet i Sverige Strategi och åtgärder för säker information i staten REMISSVAR Hanteringsklass: Öppen 2015-09-14 1 (6) Dnr 2015/633 Justitiedepartementet Enheten för samordning av samhällets krisberedskap 103 33 Stockholm Kopia: Fritzes kundservice 106 47 Stockholm Remissvar

Läs mer

Utfärdad av Compiled by Tjst Dept. Telefon Telephone Datum Date Utg nr Edition No. Dokumentnummer Document No.

Utfärdad av Compiled by Tjst Dept. Telefon Telephone Datum Date Utg nr Edition No. Dokumentnummer Document No. Stämpel/Etikett Security stamp/lable ALLMÄNNA KRAV FR YTBEHANDLING GENERAL REQUIREMENTS FOR SURFACE TREATMENT Granskad av Reviewed by Lars Åke Nilsson Tjst Dept. GUM2 tb_tvåspråkig 2006-05-09 1 (7) ÄNDRINGSFRTECKNING

Läs mer

SVENSK STANDARD SS-ISO/IEC 27001:2014

SVENSK STANDARD SS-ISO/IEC 27001:2014 SVENSK STANDARD SS-ISO/IEC 27001:2014 Fastställd/Approved: 2014-02-26 Publicerad/Published: 2014-02-27 Utgåva/Edition: 2 Språk/Language: svenska/swedish; engelska/english ICS: 01.140.30; 04.050; 33.040.40;

Läs mer

Design Service Goal. Hantering av demonterbara delar som ingår i Fatigue Critical Baseline Structure List. Presentatör

Design Service Goal. Hantering av demonterbara delar som ingår i Fatigue Critical Baseline Structure List. Presentatör Design Service Goal Hantering av demonterbara delar som ingår i Fatigue Critical Baseline Structure List Presentatör Thobias Log Flygteknisk Inspektör Sjö- och luftfartsavdelningen Enheten för operatörer,

Läs mer

IT-säkerhet Internt intrångstest

IT-säkerhet Internt intrångstest Revisionsrapport IT-säkerhet Internt intrångstest Botkyrka kommun Janne Swenson Maj 2015 Innehållsförteckning Inledning... 3 Bakgrund... 3 Revisionsfråga... 3 Väsentlighets- och riskanalys... 3 Angreppssätt...

Läs mer

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Kravfångst? Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Gästföreläsning Datavetenskap 2011-02-15 Therese Söderlund, Lars Hansson och Jan Bidner (ITS) ITS - Enheten

Läs mer

Introduktion till informationssäkerhet

Introduktion till informationssäkerhet Introduktion till informationssäkerhet Daniel Bosk Avdelningen för informations- och kommunikationssytem (IKS), Mittuniversitetet, Sundsvall. intro.tex 1586 2014-01-27 14:21:59Z danbos 2 Översikt 1 Formalia

Läs mer

Bilaga 10 Säkerhet. Dnr: / stockholm.se. Stadsledningskontoret It-avdelningen

Bilaga 10 Säkerhet. Dnr: / stockholm.se. Stadsledningskontoret It-avdelningen stockholm.se Stadsledningskontoret It-avdelningen Ragnar Östbergs Plan 1 105 35 Stockholm Växel 08-508 29 000 www.stockholm.se Innehåll 1 Inledning 3 2 Krav på säkerhetsarbete 3 2.1 Allmänt 3 2.2 Ledningssystem

Läs mer

Metodprov för kontroll av svetsmutterförband Kontrollbestämmelse Method test for inspection of joints of weld nut Inspection specification

Metodprov för kontroll av svetsmutterförband Kontrollbestämmelse Method test for inspection of joints of weld nut Inspection specification Stämpel/Etikett Security stamp/lable Metodprov för kontroll av svetsmutterförband Kontrollbestämmelse Method test for inspection of joints of weld nut Inspection specification Granskad av Reviewed by Göran

Läs mer

Riktlinjer för styrdokument

Riktlinjer för styrdokument Sida 1/10 Riktlinjer för styrdokument Verksamheten i Kungsbacka kommun styrs, förutom av sitt eget självstyre, av många olika omvärldsfaktorer som, lagar och förordningar, staten och andra myndigheter.

Läs mer

Stålstandardiseringen i Europa

Stålstandardiseringen i Europa Stålstandardiseringen i Europa Erfarenheter, möjligheter, utmaningar Hans Groth Avesta Research Center Innehåll 1. En idé om ett nytt material - Tidslinje 2. Förutsättningar Regelverket som det var då

Läs mer

Terminologi för e-legitimationer

Terminologi för e-legitimationer Terminologi för e-legitimationer Terminologi för e-legitimationer Det pratas mycket om e-legitimationer nu. Men om man försöker hitta svaret på frågan Vad är egentligen en e-legitimation för något? möts

Läs mer

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument. Riktlinjer för styrdokument 1

Strategi Program Plan Policy» Riktlinjer Regler. Borås Stads. Riktlinjer för styrdokument. Riktlinjer för styrdokument 1 Strategi Program Plan Policy» Riktlinjer Regler Borås Stads Riktlinjer för styrdokument Riktlinjer för styrdokument 1 Borås Stads styrdokument» Aktiverande strategi avgörande vägval för att nå målen för

Läs mer

EU integration Internationell Politik

EU integration Internationell Politik EU integration Internationell Politik Tisdag 12 maj 2009 Idag Definitioner vad menar vi egentligen? Kontext EU:s utvecklingspolitik EU ekonomisk supermakt Handel som bistånd Malin Stegmann McCallion 1

Läs mer

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur 2016:1 Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande

Läs mer

Metoder för datasäkerhet. Vad handlar en sådan kurs om???

Metoder för datasäkerhet. Vad handlar en sådan kurs om??? Metoder för datasäkerhet Vad handlar en sådan kurs om??? Vad avses då media rapporterar om datasäkerhet? Oftast resultat av brister i säkerheten Allt möjligt av helt olika karaktär, som Försvunna viktiga

Läs mer

InstalationGuide. English. MODEL:150NHighGain/30NMiniUSBAdapter

InstalationGuide. English. MODEL:150NHighGain/30NMiniUSBAdapter miraclebox miraclewifi InstalationGuide English MODEL:150NHighGain/30NMiniUSBAdapter ENGLISH MIRACLE WIFI 150N & 300N USERMANUAL MIRACLEBOX.SE 1 ENGLISH Table of Contents Package Contents... 3 System Requirements

Läs mer

IT-säkerhetsstandarden Common Criteria (CC) en introduktion. kbm rekommenderar 2007:2

IT-säkerhetsstandarden Common Criteria (CC) en introduktion. kbm rekommenderar 2007:2 IT-säkerhetsstandarden Common Criteria (CC) en introduktion kbm rekommenderar 2007:2 kbm rekommenderar 2007:2 IT-säkerhetsstandarden Common Criteria (CC) en introduktion vad är cc och ccra? till vad kan

Läs mer

Björn Åstrand

Björn Åstrand HÖGSKOLAN I HALMSTAD Examensarbete Instruktioner Halvtidseminarium 2014 HT Björn Åstrand 2014-10-08 Björn Åstrand 2014 1 Halvtidsseminarium Vid halvtidsseminariet presenteras hittills uppnådda resultat

Läs mer

Prototyper och användartest

Prototyper och användartest Föreläsning i webbdesign Prototyper och användartest Rune Körnefors Medieteknik 1 2012 Rune Körnefors rune.kornefors@lnu.se Prototyp för en webbplats! Utkast eller enkel variant av webbplatsen" Syfte"

Läs mer

Behov av stöd vid genomförande av hot-, risk- och sårbarhetsanalyser för IT-system inom Försvarsmakten

Behov av stöd vid genomförande av hot-, risk- och sårbarhetsanalyser för IT-system inom Försvarsmakten Behov av stöd vid genomförande av hot-, risk- och sårbarhetsanalyser för IT-system inom Försvarsmakten JOHAN BENGTSSON, KRISTOFFER LUNDHOLM, JONAS HALLBERG FOI är en huvudsakligen uppdragsfinansierad myndighet

Läs mer

Installationsguide, Marvin Midi Server

Installationsguide, Marvin Midi Server Installationsguide, Marvin Midi Server 1 Ändringsinformation... 2 2 Marvin Midi Server... 2 2.1 Inledning... 2 2.2 Förutsättningar för en framgångsrik installation... 2 2.3 Kort om installationen... 3

Läs mer