<SYSTEM> <VERSION>
ANALYSUNDERLAG DEFINIERA (AU-D)

Innehåll

Mallinformation	3

Versionshistorik för mallen	3

Generell mallinstruktion	3

Specifik mallinstruktion	3

Dokumentstruktur Definiera-fasen	3

Att tänka på i arbetet med framtagning av AU-D	4

1	Basfakta	5

1.1	Giltighet och version	5

1.2	Terminologi	5

1.3	Referenser	5

1.4	Underbilagor	5

2	Inledning	7

2.1	Syfte	7

2.2	Dokumentöversikt	7

3	Analys av indata	8

4	Kompletterande analyser	9

4.1	Verksamhetsanalys	9

4.2	Regelverksanalys	10

4.3	Säkerhetsanalys	10

4.4	Samråd med Försvarsmakten	11

5	Beskrivning av kravspårningsmetod	12

6	Redovisning av kravspårning	14

7	Inte tillämpbara krav	15

8	Krav på evaluerarens aktiviteter	16

9	Kravpåverkan av designregler	18

Mallinformation

Versionshistorik för mallen

Datum	Version	Beskrivning	Ansvarig	Fastställd
2021-05-19	1.0	ISD 3.1	Ulf Christensen

Generell mallinstruktion

Detta kapitel är information om mallen och innehåller anvisningar avsedda att hjälpa författaren. Kapitlet ska raderas i sin helhet innan dokumentet färdigställs.

Röd text (som denna) är en vägledning till författaren av dokumentet och ska raderas innan dokumentet färdigställs.

Text som befinner sig innanför ”<“ och ”>” uppdateras eller tas bort. T.ex. ska <system><version> ersättas med informationssystemets namn och version (d.v.s. det IT-system som ska ackrediteras).

Övrig svart text kan användas i det färdigställda dokumentet.

Specifik mallinstruktion

Denna mall används för att skapa dokumentet AU-D i ISD-processens Definiera-fas.

FMV Projektledare är ansvarig för AU-D.

Eftersom AU-D är en bilaga till ISD-D så godkännden när ISD-D godkänns.

Dokumentstruktur Definiera-fasen

Dokumentstrukturen för ISD-processens Definiera-fas illustreras nedan och visas hur ISD-planen styr ISD-arbetet som resulterar i ISD-D sina bilagor.

ISD-planen styr ISD-arbetet i genomförandeprojektet. Planen klargör förutsättningar och utmaningar, vilka aktiviteter och leveranser som ska genomföras och deras tidplan, vilka kompetenser som behövs, och vilken projektsamverkan som behöver finnas.

ISD-D dokumenterar bedömning av realiserbarhet avseende informationssäkerhet för genomförandeprojektet och systemet.

AU-D kan innehålla; analys av indata, kompletterande analyser, beskrivning av kravspårningsmetod, redovisning av kravspårning, hantering av inte tillämpbara krav, förteckning av krav som ska hanteras av evalueraren (som innehas av ISD-rollerna ISE och ISTM) samt redovisning av omhändertagande av designregler.

ITSS-D bygger vidare på ITSS-I (eller på FM ITSS om ingen ITSS-I finns) med tolkade och allokerade informationssäkerhetskrav, till en detaljnivå att kraven kan användas för upphandling och verifiering.

ITSA dokumenterar säkerhetsarkitekturen som dels uppfyller informationssäkerhetskraven och dels harmoniserar med System Engineering-arbetet i projektet.

Att tänka på i arbetet med framtagning av AU-D

Lämplig kompetens för att utarbeta AU-D innehas av ISD-rollen ISA, med stöd av ISM-rollen.

Arbetet med AU-D, ITSS-D och ITSA hänger samman och bör utföras parallellt.

Basfakta

Giltighet och version

Detta dokument är Analysunderlag i ISD-processens Definiera-fas (AU-D) för <informationssystem><version> inför FMV VHL T2- och T3-beslut.

Datum	Version	Beskrivning	Ansvarig
<datum>	Initial version

Tabell 1 – Versionshistorik

Terminologi

Se referens [1] för en generell förteckning över de begrepp och förkortningar som används inom ISD-processen. Följande tabell innehåller specifika begrepp och förkortningar som används i detta dokument.

Begrepp/förkortning	Definition/förklaring

Tabell 2 – Begrepp och förkortningar

Referenser

Använd kommentarskolumnen i tabellen nedan för att vid behov ange t.ex. status, klassning, utgivande organisation, författare eller årtal.

Referens	Beteckning	Kommentar
ISD v3.1, Begrepp och förkortningar	20FMV5903-1:1.1
Beslut om krav på godkända säkerhetsfunktioner version 3.1 (KSF v3.1	FM2014-5302:1
Handbok Försvarsmaktens säkerhetstjänst, Informationssäkerhet; H SÄK Infosäk 2013	M7739-352056
Reglemente Säkerhetstjänst, R SÄK 2021	M7739-353149

Tabell 3 – Referenser

Underbilagor

Om detta dokument har några underbilagor ska de noteras här, annars radera nedanstående och skriv ”Inga underbilagor.”

Detta dokument har följande underbilagor:

Underbilaga 1: <titel på underbilaga 1>

...

Inledning

Syfte

Syftet med AU-D är att dokumentera analyserna av de förutsättningar och kravrelaterade aspekter i ISD-arbetet som inte fångas upp av varken ITSS-D eller ITSA.

Dokumentöversikt

Dokumentet innehåller följande delar:

Analys av indata

Kompletterande analyser

Beskrivning av kravspårningsmetod

Redovisning av kravspårning

Hantering av krav som inte är tillämpbara på informationssystemet

Förteckning av krav som ska hanteras av evalueraren.

Redovisning över omhändertagande av designregler

Delarna återfinns i respektive kapitel i dokumentet.

Analys av indata

Detta kapitel redovisar analyserad indata och dess eventuella bister.

Har analys av indata hanterats i ISD-processens Identifiera-fas och ingen ny indata behöver analyseras skriv ”Inget förnyat behov av att analysera indata.”.

Analys av indata från FÖRSVARSMAKTEN görs med syfte att identifiera brister i indata som riskerar att systemet inte blir realiserbart ur ett informationssäkerhetsperspektiv.

Se anvisningar i mallen för huvuddokumentet ISD-D vad som ingår i en realiserbarhetsbedömning i denna fas.

Visar analysen att det finns brister i indata som behöver åtgärdas finns det en av två vägar att gå:

Bristerna påtalas för Försvarsmakten som åtgärdar (eventuellt med hjälp av FMV) och som därefter tillhandahåller uppdaterad eller kompletterad indata. FMV gör därefter en förnyad analys av indata.

Bristerna påtalas för Försvarsmakten men som inte har möjlighet att åtgärda dem. FMV genomför då kompletterande analyser och dokumenterar dessa i denna AU-D. Därefter genomförs samråd med Försvarsmakten om resultatet från analyserna så att acceptans uppnås av båda parter. Kraven som kommer ur analyserna kommer att hanteras såsom krav från Försvarsmakten och visas uppfyllnad av i Informationssäkerhetsdeklarationen.

En del indata från Försvarsmakten kan bestå i styrande referenser till designregler, instruktioner, handböcker och liknande. Sådan styrning kompletterar kravbilden och kan även göra den tydligare. Försvarsmakten ger ut ett dokument ”Sammanställning över bestämmelser och riktlinjer för säkerhetstjänsten (SAMSÄK)” en gång om året. Detta dokument förtecknar samtliga säkerhetsrelaterade och gällande internationella säkerhetsskyddsåtaganden, lagar och förordningar. Här ingår också föreskrifter, FFS, FIB, handböcker, instruktioner och skrivelser utgivna av Försvarsmakten. Vid bedömning av indata kan SAMSÄK användas för att kontrollera om det är någon styrande referens som saknas i Försvarsmakten kravställning och som borde ingått. Kontrollfråga kan i förekommande fall ställas till Försvarsmakten. SAMSÄK finns för närvarande länkad i denna websida: https://www.forsvarsmakten.se/sv/organisation/hogkvarteret/militara-underrattelse-och-sakerhetstjansten/

<Lista indata som analyserats och beskriv de brister som framkom i analyserna.>

Kompletterande analyser

Kompletterande analyser används då det har framkommit, i föregående kapitel, att indata har brister som behöver åtgärdas och att det är FMV som ska genomföra åtgärderna. Dessa analyser kompletterar då indata och förbättrar därmed förutsättningarna för ISD-arbetet.

De avsnitt som anges nedan motsvarar analyser som ska genomföras när en Särskild säkerhetsskyddsbedömning från Försvarsmakten utvecklas. Finns behov av andra analyser kan fler avsnitt läggas till.

Om inga kompletterande analyser genomförts, skriv ”Inga kompletterande analyser har genomförts” och radera alla efterföljande avsnitt.

De kompletterande analyserna är dokumenterade i detta kapitel.

Verksamhetsanalys

Verksamhetsanalysen beskriver vad informationssystemet ska stödja verksamheten med. Den ska beskriva vilka slags uppgifter som informationssystemet ska behandla, deras värde för verksamheten samt verksamhetens krav på skydd, riktighet och tillgänglighet. En verksamhetsanalys utgör en utgångspunkt för regelverksanalys och säkerhetsanalys. Verksamhetsanalysen är också det som sätter KSF-kraven i sin kontext och som möjliggör att en IT-säkerhetsarkitektur kan utvecklas och KSF-kraven tolkas.

Om någon verksamhetsanalys inte utförts eller är inaktuell, kan den genomföras och redovisas här. Stöd om vad som ingår i en verksamhetsanalys finns i H SÄK Infosäk. Från denna analys framkommer verksamhetens krav på informationssäkerhet. Dessa krav överförs till ITSS-D som ”Tillkommande säkerhetskrav”.

Följande text är ett utdrag från H SÄK Infosäk:

Följande punkter är en vägledning för att utarbeta sådana beskrivningar.

Vilken verksamhet ska IT-systemet stödja?

Nationellt – internationellt?

Fred – kris – krig?

Kommer personal från en annan stat eller mellanfolklig organisation använda IT-systemet?

Är IT-systemet avsett för användning utanför Försvarsmaktens objekt, lokaler och områden?

Är IT-systemet avsett för distansarbete?

Vem har ansvaret för den verksamhet som IT-systemet ska stödja?

Vem har ansvaret för IT-systemet och i vilken roll?

Vilka resurser finns för att skydda IT-systemets delar och informationen i dessa?

Vilka andra verksamheter eller organisationsenheter är beroende av den verksamhet som IT-systemet ska stödja?

Vilka funktioner – vilken information?

Vilka (andra) verksamheter eller organisationsenheter är beroende av IT-systemet?

Vilka funktioner – vilken information?

Behandlad information

Vilken typ av information är IT-systemet avsett att behandla?

Sekretessbedömning.

Finns begränsningar av vem som får behandla uppgifter i IT-systemet?

Finns begränsningar för personal från en annan stat eller mellanfolklig organisation att ta del av uppgifter som behandlas i IT-systemet?

Finns begränsningar (caveat) i att delge eller använda uppgifter som avses behandlas i IT-systemet?

Verksamhetens krav på tillgänglighet.

Verksamhetens krav på riktighet.

Verksamhetens krav på spårbarhet

Verksamhetens behov av nödöppning.

Kommunikation

Vilket behov finns att överföra information på flyttbara lagringsmedier?

Vilket behov finns att överföra information genom elektroniska kommunikationsnät?

Övrig kommunikation till andra IT-system?

<Verksamhetsanalys>

Regelverksanalys

En regelverksanalys syftar till att beskriva vilka lagar, förordningar, föreskrifter, bestämmelser och andra regler som är aktuella för informationssystemet och för de uppgifter det ska behandla.

Om regelverksanalysen utförts eller är inaktuell, ska den genomföras och redovisas här. Stöd om vad som ingår i en verksamhetsanalys finns i H SÄK Infosäk, referens[3]. Från denna analys framkommer tillkommande krav på informationssäkerhet i form av regelverkskrav. Dessa krav överförs till ITSS-D som Tillkommande säkerhetskrav.

<Regelverksanalys>

Säkerhetsanalys

Säkerhetsanalysen identifierar och prioriterar alla skyddsvärda tillgångar som kommer bearbetas, lagras eller på annat sätt hanteras av systemet (inklusive systemet självt). Därefter görs en bedömning av vilken konsekvens som uppstår och omfattningen av denna om uppgifter rörande de identifierade tillgångarna utsätts för en oönskad händelse. Arbetet avslutas med en hot-, risk- och sårbarhetsanalys följt av en riskhantering.

Om säkerhetsanalysen inte utförts eller är inaktuell ska den genomföras och redovisas här. Stöd om vad som ingår i en säkerhetsanalys finns i H SÄK Infosäk, referens [3] och R SÄK 2021, referens [4]. De krav på informationssäkerhet som framkommer överförs till ITSS-D som ”Tillkommande säkerhetskrav”.

<Säkerhetsanalys>

Samråd med Försvarsmakten

De kompletterande analyserna leder fram till krav som kan påverka kostnader, prestanda, förmågor och verksamheten. Det är därför viktigt att det finns en dokumenterad acceptans av det som FMV har kommit fram till och som härifrån blir styrande för projektet.

De kompletterande analyserna som dokumenterats här har accepterade av Försvarsmakten och FMV och gäller för informationssystemet. Denna överenskommelse har skapats genom följande samråd:

<referera till mötesprotokoll/granskningsrapport/eller dylikt som kan bekräfta samråden>

Beskrivning av kravspårningsmetod

Oavsett storlek och komplexitet på projektet krävs en definierad metod för tydlig kravspårning från Försvarsmaktens kravställning i Särskild säkerhetsskyddsbedömning, till FMVs Informationssäkerhetsdeklaration(ISD) i slutet av projektet. Detta avsnitt kan användas för att beskriva den metod som använts, eller referera till det dokument där metoden beskrivs.

Detta kapitel beskriver tillämpad kravspårningsmetod.

Nedan beskrivs några aspekter som behöver hanteras i en beskrivning av kravspårningsmetodiken.

Kravspårningsmetoden behöver normalt hantera att källkrav delas upp i flera nya krav, att ett nytt krav uppfyller flera källkrav eller både och. Se Figur 1, Figur 2 och Figur 3 för illustration av de olika varianterna nedan.

Figur 1 – Kravspårning [1:1]. Ett källkrav uppfylls till fullo av ett nytt krav.

Figur 2 – Kravspårning [1:n]. Ett källkrav uppfylls till fullo av flera nya krav i samverkan.

Figur 3 – Kravspårning [n:1]. Flera källkrav uppfylls till fullo av ett nytt krav.

Det finns även en variant som innebär att flera källkrav uppfylls av flera nya krav. Detta bör undvikas då det introducerar en komplexitet där det är svårt att påvisa att källkraven till fullo är uppfyllda.

En annan aspekt som behöver hanteras i kravspårningsmetodiken är namngivning av kravidentiteterna. Förutom att kraven behöver ha unik identitet kan det vara fördelaktigt att det finns en logik i kravidentiteten (Krav ID) för enklare förståelse för t.ex. varifrån ett visst krav härstammar eller vad det är för typ av krav. Det finns även förespråkare för att undvika att lägga logik i Krav ID och istället använda löpnummer. Oavsett behöver metoden beskrivas.

Ytterligare en aspekt på kravspårningsmetodik är hur i många steg ett krav tillåts brytas ned (tolkas). Ytterlighetsfall är att ingen nedbrytning görs vilket innebär att det är källkravet som används för att både designa, implementera och verifiera. Detta går oftast inte med de funktionella KSF-kraven då de är utformade generellt och saknar grundläggande kravegenskaper såsom att vara specifika. De funktionella KSF-kraven kräver alltså som regel en nedbrytning (tolkning) för att skapa implementerbara och verifierbara krav.

Kravarbetet genomförs med fördel med hjälp av datorstöd, t.ex. specialiserat kravhanteringsverktyg som Doors eller generellt verktyg som Excel. Oavsett verktyg behöver alla krav och kravspårning vid olika tillfällen dokumenteras i Word-dokument för redovisning och fastställande. I beskrivningen av kravspårningsmetodiken behöver det framgå hur kravspårningen redovisas i Word-dokument; t.ex. hur tabeller används och vilka kolumner de ska innehålla.

Slutligen kan nämnas att kravhantering är en ingenjörsdisciplin som på engelska heter Requirements Engineering och att ovanstående aspekter endast är ett axplock av saker att definiera där omfattande kravarbete förväntas. Denna typ av expertis brukar t.ex. anse att det först av allt behöver skapas en metamodell som definierar storheterna som ska hanteras (KravID, Kravtext, Kravkategori, etc.) och relationerna mellan dessa (riktning, valbarhet, etc.).

<Beskriv kravspårningsmetoden>

Redovisning av kravspårning

Beroende på kravspårningsmetod kan redovisningen (själva spårningen) göras i ITSS-D och ITSS-R. Sker all kravspårning någon annanstans radera då nedanstående och skriv ”Kravspårning redovisas i <ref>”. Om inget naturligt dokument finns att redovisa i används detta kapitel.

Detta kapitel redovisar kravspårning från källkrav till nya krav.

<Redovisa kravspårning>

Inte tillämpbara krav

Detta kapitel listar och motiverar varför samtliga källkrav som inte är tillämpbara på varken informationssystemet eller dess omgivning.

Samtliga krav som Försvarsmakten ställt på informationssystemet ska uppfyllas. Det kan dock vara så att vissa krav saknar relevans för informationssystemet ifråga.

Notera dock att varken tidsbrist eller svag ekonomi normalt sett anses vara en giltiga anledningar för att avfärda krav. En sådan situation ska istället lösas med riskhantering.

Avsluta inte tillämpbara krav så tidigt som möjligt i processen eftersom det minskar komplexitet på kravhanteringen. Är alla krav tillämpbara, radera då nedanstående och skriv ”Alla krav är tillämpbara”.

Exempel:

Krav ID	Kravtext	Orsak till att kravet inte är tillämpbart
SFSL_OAV.1	Alla förändringar till placering i informationssäkerhetsklass samt förändringar gällande märkning av objekt med skyddsvärde ska bindas till användaren med en oavvislighetsmekanism.	IT-systemet hanterar inte information med olika informationssäkerhetsklasser.
SFID_DAT.2	Trafikdata från relevant kommunikation mellan komponenter i systemet ska göras tillgängligt för analys.	IT-systemet är en stand-alone dator som inte har någon nätverkskoppling och som endast består av en komponent.

Krav ID	Kravtext	Orsak till att kravet inte är tillämpbart

Tabell 4 – Krav som inte går att tillämpa på varken informationssystemet eller driftmiljön, med motivering

Krav på evaluerarens aktiviteter

Detta kapitel avhandlar KSF-kraven på evaluerarens aktiviteter, referens [2]. Här redovisas även precisering, tolkning, av kraven i de fall det krävs.

Detta avsnitt hanterar de E-krav från KSF som evalueraren ska hantera (d.v.s. assuranskrav vars kravidentifierare slutar med ett ”E”). Dessa krav är ställda på aktiviteter för evaluering av informationssystemet som är tänkt ska genomföras av evaluerare. Evalueraren innehar ISD-rollerna ISE eller ISTM på FMV. Under ISD-processens Realisera-fas ska evalueraren hantera och redovisa kravuppfyllnaden för dessa krav.

Även kravklassen SASS (krav på utformning och innehåll på ITSS) och SATS_EVL (evaluerarens testning) hanteras här. Dessa krav redovisar evalueraren uppfyllnad för, senare i AU-R, i Realisera-fasen.

Normalt finns det ett begränsat behov av att tolka kraven på evaluerarens aktiviteter eftersom de oftast är tillräckligt tydliga. Det kan dock finnas en anledning till att omformulera kraven och i så fall måste kravspårning finnas (t.ex. att översätta dem till annat språk ).

Kraven på evaluerarens aktiviteter hanteras alltså inte i varken ITSS-D eller ITSS-R där alla andra informationssäkerhetskrav hanteras. Istället hanteras kraven i detta Analysunderlag (AU-D) och med kravuppfyllnadsredovisningen i AU-R. För att få en korrekt kravspårning behöver därför samtliga krav på evaluerarens aktiviteter hanteras i detta kapitel, oavsett som de preciserats eller inte.

Som förslag kan någon av följande tabeller användas, beroende på om det görs nya krav på grund av precisering eller om källkravet kan användas såsom utformat. Kommentarskolumnen kan användas för att t.ex. ange saker att tänka på vid evaluerarens utarbetning av kravuppfyllnad.

Nytt Krav ID	Ny kravtext	Kommentar	Källa

Tabell 5 – Krav på evaluerarens aktiviteter. Kraven är preciserade (tolkade). Källa anger kravidentifieraren från KSF [2].

Kravtext	Kommentar	Källa

Tabell 6 – Krav på evaluerarens aktiviteter. Källa anger kravidentifieraren från KSF [2].

Sammanfattningsvis är följande krav aktuella för hantering i detta kapitel. Notera dock att kravmängden skiljer beroende på KSF-kravnivå. Finns en FM ITSS eller ITSS-I hämtas kraven därifrån.

SASS – samtliga krav

SALC – E-kraven

SADE – E-kraven

SAOP – E-kraven

SARU – E-kraven

SATS – E-kraven och SATS_EVL

SARA – E-kraven

Kravpåverkan av designregler

I detta kapitel redovisas omhändertagandet av de designregler som är styrande för informationssystemet eller projektet.

Designregler som ingår som styrande förutsättningar för ISD-arbetet ska omhändertas. Att omhänderta en designregel sker genom att tolka dess innehåll i relation till kravställt informationssystem och låta resultatet påverka både design och kravbild. Kravbilden kan påverkas genom att preciseringen (tolkningen) av kraven omhändertar delar av en designregel eller att det uppstår nya krav baserat på designregeln.

Syftet med detta kapitel är att redogöra för hur samtliga designregler omhändertagits Det ska också redogöras för hur design och kravbild påverkas.

Nedan följer exempel på omhändertagande av några av reglerna i designregeln för Härdning av informationssystem.

ID	Designregel	Tolkning	Berör	Påverkan	Åtgärd
Regel 1	Krav SFIS_HRD.2 i KSF 3.1 ska tolkas enligt följande: Ingående delar i systemet ska konfigureras i enlighet med av IT-säkerhetsbranschen vedertagna rekommendationer för säker konfiguration av komponenttypen. Om sådan inte finns ska tillverkarens rekommendationer för säker konfiguration användas.	Då Windows 10 används i detta IT-system finns det vedertagna rekommendationer på CIS. För KrAPI finns inte detta och här ska tillverkarens anvisningar tillämpas.	SFIS_HRD.2	Designregeln har direkt påverkan.	Precisering av SFIS_HRD.2 ska omhänderta designregeln.
Regel 2	Med ”av IT-säkerhetsbranschen vedertagna rekommendationer” enligt Regel 1 avses CIS – Center for Internet Securitys härdningsrekommendationer s.k. CIS benchmarksTM.	Förtydligande av Regel 1	SFIS_HRD.2	Designregeln har direkt påverkan.	Precisering av SFIS_HRD.2 ska omhänderta designregeln.
Regel 3	Om relevanta CIS benchmarks saknas för i IT-systemet ingående komponenttyper ska respektive tillverkares rekommendationer för säker konfiguration användas. Saknas även rekommendationer från tillverkaren ska eventuella andra relevanta rekommendationer användas. Vid tillämpning av Regel 3 ska samverkan avseende bedömning av olika alternativ ske med FMV kravföreträdare (KravF) IT-säk.	Inga komponenter som används i IT-systemet saknar både CIS benchmarks och rekommendationer från tillverkaren.	Ingen påverkan.	Ingen åtgärd.

ID	Designregel	Tolkning	Berör	Påverkan	Åtgärd

Tabell 7 – Omhändertagande av <namn och referens till designregeldokumentet>