<SYSTEM> <VERSION>
IT-SÄKERHETSARKITEKTUR (ITSA)

Innehåll

Mallinformation	4

Versionshistorik för mallen	4

Generell mallinstruktion	4

Specifik mallinstruktion	4

Dokumentstruktur Definiera-fasen	4

Att tänka på i arbetet med framtagning av ITSA	5

1	Basfakta	6

1.1	Giltighet och version	6

1.2	Terminologi	6

1.3	Referenser	6

1.4	Underbilagor	6

2	Inledning	7

2.1	Syfte	7

2.2	Innehåll	7

2.3	Samverkan med System Engineering	7

3	Förutsättningar	8

3.1	Styrande förutsättningar	8

3.2	Avgränsningar	8

3.3	Beroenden till andra tekniska system	8

3.4	ISD designbeslut	9

3.5	Övriga förutsättningar	9

3.5.1	Arkitekturprinciper	9

4	Systembeskrivning	11

4.1	Systemöversikt	11

4.2	Verksamhetsbeskrivning	11

4.3	Användare	12

4.4	Driftmiljö	12

4.5	Information	12

4.6	Användningsfall	12

4.7	Systemets arkitektur	12

4.8	Systemets externa gränsytor	13

4.8.1	Fysiska externa gränsytor	13

4.8.2	Logiska externa gränsytor	13

4.9	Avgränsning av ackrediteringsobjektet	13

4.10	Säkerhetsförmågor	14

5	Säkerhetsarkitektur	15

5.1	Säkerhetsfunktionskedjor	15

5.1.1	Säkerhetsfunktionskedja för gemensam tid	15

5.1.2	Säkerhetsfunktionskedja för behörighetskontroll	15

5.1.3	Säkerhetsfunktionskedja för säkerhetsloggning	15

5.2	Säkerhetsfunktioner	15

5.2.1	Behörighetskontroll	16

5.2.2	Säkerhetsloggning	16

5.2.3	Intrångsskydd	16

5.2.4	Intrångsdetektering	16

5.2.5	Skydd mot skadlig kod	16

5.2.6	Skydd mot obehörig avlyssning	16

5.2.7	Skydd mot röjande signaler	16

5.2.8	Integritetsskydd	17

5.2.9	Redundans och reserv	17

5.2.10	Säkerhetskopiering	17

5.2.11	Säker tid	17

5.2.12	Säkert tillstånd	17

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 innehåller information avsedd att hjälpa författaren till dokumentet. Kapitlet ska raderas i sin helhet innan dokumentet färdigställs.

Röd text (som denna) är en vägledning till författaren 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 ITSA i ISD-processens Definiera-fas.

FMV Projektledare är ansvarig för ITSA.

ITSA är en bilaga till ISD-D och godkänns i och med att huvuddokumentet ISD-D godkänns.

Dokumentstruktur Definiera-fasen

Dokumentstrukturen för ISD-processens Definiera-fas illustreras nedan. Här visas att ISD-planen styr ISD-arbetet som resulterar i dokument ISD-D med dess tre bilagor.

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

ISD-D deklarerar realiserbarheten av informationssystemet utifrån informationssäkerhetens perspektiv.

AU-D innehåller bl.a. de analyser som genomförts, redovisning av kravspårning, hantering av inte tillämpbara krav, förteckning över krav som ska hanteras av evalueraren samt redovisning över hur designreglerna omhändertagits.

ITSS-D bygger vidare på ITSS-I (eller på FM ITSS om ingen ITSS-I finns) med tolkade och allokerade informationssäkerhetskrav, på 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 ITSA

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

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

Basfakta

Giltighet och version

Detta dokument är IT-säkerhetsarkitektur (ITSA) i ISD-processens Definiera-fas 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 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

Tabell 3 – Referenser

Underbilagor

Om detta dokument har underbilagor ska dessa förtecknas 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 detta dokument är att specificera en utarbetad säkerhetsarkitektur som uppfyller ställda krav från både Försvarsmakten och FMV i en ackrediteringsbar lösning.

Krav från KSF kräver precisering (tolkning) för att kunna användas som kravställning till leverantör och för att kunna verifieras. ITSA används för att tolka och allokera krav på olika komponenter i informationssystemet och dess omgivning. Möjlighet finns att använda ITSA för att förankra FMVs tolkade och föreslagna säkerhetslösning med Försvarsmakten.

ITSA används även som underlag för realiserbarhetsbedömningen som redovisas i ISD-D och ISD-R. För ISD-R bedöms det hur väl det framtagna informationssystemet överensstämmer med beskrivningen som redovisats i detta dokument.

Innehåll

Innehållet i ITSA visar hur säkerhetsfunktionerna:

Fördelas på komponenter i informationssystemet och omgivningen.

Används av informationssystemet och användarna

Integrerar med varandra och informationssystemet.

Samverkan med System Engineering

Säkerhetsarkitekturen har utarbetats i samverkan med System Engineering. I detta arbete har en systemarkitektur skapats som omhändertar både funktionella delar och informationssäkerhetsperspektivet.

Om ingen samverkan gjorts ska stycket ovan ersättas med följande:

Säkerhetsarkitekturen har inte utarbetats i samverkan med System Engineering. Analys av möjlig säkerhetspåvekan på slutlig lösning har gjorts med följande resultat

<beskriv möjlig säkerhetspåverkan på slutlig lösning på grund av att samarbete inte gjorts med System Engineering>.

Förutsättningar

Detta kapitel redogör förutsättningarna för informationssäkerheten och vad säkerhetsarkitekturen ska uppfylla.

Dessa förutsättningar härstammar från olika källor:

Krav från Försvarsmakten (Särskild säkerhetsskyddsbedömning, ITSS, beslut, skrivelser m.m.)

Krav från FMV designledning (designregler m.m.)

Krav från FMV projekt (specifika krav, krav på samverkan m.m.)

Krav från ISD-processen (processansvisningar, beslut m.m.)

Aktuell best practice inom informationssäkerhet (designprinciper m.m.)

ISD-planen och analysunderlagen (AU-I/AU-D) är de huvudsakliga källorna för ITSA-arbetet. Förutsättningar som är givna av Försvarsmakten finnas redovisat i FM ITSS/ITSS-I/ITSS-D men inte övriga förutsättningar. Därför behöver samtliga förutsättningar redogöras för i detta kapitel så att läsaren får en total bild. Notera att den kompletta kravbilden med tolkade och allokerade krav, ska redovisas i ITSS-D.

Styrande förutsättningar

Detta avsnitt beskriver det underlag som styr framtagning av säkerhetsarkitekturen.

Återge här de relevanta styrande förutsättningarna som listats i ISD-planen, AU-I och AU-D, eventuellt kompletterat med färskare information. Här ska bl.a. kravunderlag från FM och FMV ingå.

<Styrande förutsättningar>

Avgränsningar

Detta avsnitt redogör för de avgränsningar som gjorts inom säkerhetsarkitekturen.

Återge i detta avsnitt de relevanta avgränsningarna som listats i ISD-planen, AU-I och AU-D, eventuellt kompletterat med färskare information.

<Avgränsningar>

Beroenden till andra tekniska system

Detta avsnitt beskriver de beroenden informationssystemet har med andra tekniska system.

Återge i detta avsnitt de relevanta beroenden som finns till andra tekniska system (beskrivits i ISD-planen, AU-I och AU-D). Eventuellt kompletterat med färskare information.

<Beroenden till andra tekniska system>

ISD designbeslut

Detta avsnitt sammanställer de designbeslut som tagits inom ISD-projektet och som har påverkan på säkerhetsarkitekturen.

Ange om det tagits några ISD-specifika designbeslut. Om inte, ange ”Inga ISD-specifika designbeslut har tagits.”.

Eempel: Systemkomponenter (brandvägg, krypto, diod, kortläsare etc.) eller viss mjukvara (FM Tunnel, antivirus etc.).

Pos	ISD designbeslut	Källa

Tabell 4 – ISD designbeslut

Övriga förutsättningar

Arkitekturprinciper

Tabell 5 listar arkitekturprinciperna som ska tillämpas på säkerhetsarkitekturen. Här redovisas också hur respektive princip tillämpas.

Det finns olika principer att följa vid utformning av säkra informationssystem. Tabellen nedan är förslag på lämpliga principer och anpassas vid behov.

Arkitekturprincip	Beskrivning	Tillämpning i säkerhetsarkitekturen
Minimalism	Säkerhetsfunktioner skall inte göra mer än nödvändigt. Mer komplexa mekanismer innebär även större risk för sårbarheter eller att något inte fungerar som avsett. Detta ska avspegla sig i designval av systemet.
Least privilege	Varje applikation eller användare ska åberopa så få privilegier som möjligt. Behörigheten skall alltid minimeras och anpassas efter den specifika uppgift som ska lösas och inte tilldelas högre behörighet än vad uppgiften kräver.
Redundancy	Funktioner ska ha kapacitet för att hantera hög belastning och systemfel (inklusive fysiska fel).
Defence in depth	En säkerhetslösning ska inte förlita sig på att tidigare säkerhetsfunktioner fungerar eller att det finns ett beroende till dem. Ett värsta scenario ska alltid antas vara gällande och systemet ska använda sig av flera, av varandra oberoende säkerhetsfunktioner. Tillsammans ska dessa konstruera en säkerhetsdesign som upprätthåller IT-säkerheten i systemet.
Self-protection	Funktioner ska inte ha onödiga beroende till andra funktioner/domäner.
Controlled data flow	Informationsutbyte ska följa väl definierade mönster, som är under central kontroll.
Balanced strength	Det ska finnas en balans i styrkan hos säkerhetsfunktionerna i hela systemet.
Hardening	Systemet ska härdas så att applikationer eller funktioner som inte är nödvändig för att upprätthålla systemet och dess säkerhetsfunktioner avinstalleras eller stängs av.

Tabell 5 – Arkitekturprinciper som tillämpas

Systembeskrivning

Detta kapitel framställer en beskrivning av informationssystemet med fokus på de säkerhetsrelaterade aspekterna. Beskrivningen ligger till grund för utarbetning av säkerhetsarkitekturen som presenteras i efterföljande kapitel.

Lämpligen utvecklas systembeskrivningen i samarbete med System Engineering för att få fram en balanserad lösning som uppfyller samtliga krav som ställs på informationssystemet. Systembeskrivningen som redovisas i detta kapitel är resultatet av det arkitektur- och designarbete på FMV som anses vara bäst lämpat för att realiseras. Från denna arkitektur och design skapas kravbilden som ska gälla för det upphandlade och verifierade informationssystemet.

Systembeskrivningen som återges här behöver endast innehålla de aspekter på informationssystemet som har en påverkan på säkerheten och som behövs för att förstå design och kravställning. Systembeskrivningen ska alltså ge läsaren det kontext som behövs för att kunna ta till sig den beskrivning av säkerhetsfunktionerna och en specificerad (tolkad) kravställning som specificeras i ITSS-D och AU-D.

En systembeskrivning kan utformas på olika sätt. Efterföljande förslag på underavsnitt kan anpassas efter behov.

Både denna ITSA och ITSS-D innehåller en systembeskrivning. Det rekommenderas att utforma en gemensam systembeskrivning om det passar i båda dokumenten Om ena systembeskrivningen behöver vara djupare eller ha ett annat fokus än den andra för att fylla sina syften. I så fall kan det vara aktuellt att skapa två separata systembeskrivningar, där den ena hänvisar i delar till den andre för att minimera upprepningar.

Systemöversikt

Detta avsnitt beskriver informationssystemet på en översiktlig nivå för att skapa en bild av syftet med och vilken typ av informationssystem det är.

<Lägg in en figur som illustrerar systemöversikten och ge en beskrivning till figuren>

Verksamhetsbeskrivning

Detta avsnitt beskriver verksamheten som informationssystemet ska stödja.

Beskriv verksamheten som informationssystemet ska stödja och hur detta stöd ska ske ur användarens perspektiv. Använd termer som förmågor, användarroller, samt bearbetning, lagring och överföring av information.

Det ska också framkomma om informationssystemet går att använda i militära operationer och övningar för svenska eller internationella förband. Som hjälp för att få med relevant innehåll i beskrivningen kan H SÄK Infosäk konsulteras, under avsnitt 14.2 Verksamhetsanalys.

Finns denna beskrivning i annat dokument, t.ex. Särskild säkerhetsskyddsbedömning från Försvarsmakten, AU-I eller AU-D, referera dit istället för att upprepa texten.

<Beskriv avsedd användning av systemet>

Användare

Detta avsnitt beskriver informationssystemets tänkta användare. Alla användarroller redovisas och eventuell gruppering av användare efter åtkomst till resurser och information identifieras. För varje användarroll listas dess nivå av tillgång till informationssystemets olika säkerhetsfunktioner och andra säkerhetsrelevanta tillgångar. Antalet användare i varje roll och grupp bedöms också så att läsaren förstår informationssystemets omfattning.

Det ska även anges om det finns behov av root/Administratör/Superuser.

Om det finns en Access Control Policy för det aktuella informationssystemet, ska informationen i detta avsnitt överensstämma med den.

<Beskriv tänkta användare och deras rättigheter>

Driftmiljö

Detta avsnitt beskriver driftmiljön för informationssystemet.

Beskriv informationssystemets placering i den aktuella driftmiljön genom att beskriva information om fysiskt skydd, tillträdesbegränsning och andra säkerhetsrelevanta förutsättningar.

Det ska även beskrivas om det finns stödjande system, d.v.s. system som tillhandahåller säkerhetsfunktioner som informationssystemet är beroende av.

T.ex. ett externt system för insamling av säkerhetsloggar.

<Beskriv systemets driftmiljö>

Information

Detta avsnitt beskriver informationen som hanteras i informationssystemet.

Beskriv typ av information, mängd, skyddsvärde, sekretessklassning, andra hanteringsregler så som lagkrav kring data som hanteras i informationssystemet.

Observera att komplexa informationssystem kan ha olika säkerhetsskyddsklassificering av uppgifter i olika säkerhetsdomäner. Om så är fallet ska klassificeringen anges per säkerhetsdomän.

<Beskriv informationen i systemet>

Användningsfall

Detta avsnitt beskriver användningsfallen som informationssystemet ska hantera på ett säkert sätt.

Detta avsnitt beskriver de användningsfall som ger åtkomst till skyddsvärda uppgifter eller funktion i informationssystemet.

<Beskriv informationssystemets säkerhetsrelevanta användningsfall>

Systemets arkitektur

Detta avsnitt beskriver informationssystemets komponenter och hur dessa samverkar.

För att kunna identifiera säkerhetskraven för informationssystemet är det nödvändigt att specificera den övergripande arkitekturen. Arkitekturbeskrivningen ska identifiera informationssystemets komponenter, beskriva hur de samverkar och visa vilka informationsflöden som finns.

Systemarkitekturen ska byggas på ett sådant sätt att den har förmåga att skydda informationssystemet för hot i och utanför systemet.

Det finns verktyg för att arbeta med systemarkitekturen där resulterande bilder och information kan kopieras in i ITSA.

Ett exempel på sådant verktyg är Enterprise Architecht (EA) från Sparx Systems.

<Beskriv systemets arkitektur>

Systemets externa gränsytor

Detta avsnitt beskriver informationssystemets fysiska och logiska gränsytor.

Informationssystemets alla logiska och fysiska externa gränsytor ska identifieras och beskrivas. Med externa avses de gränsytor som är mellan informationssystemet och driftmiljön. Beskrivningen ska innehålla:

Definition av gränssnitt och fysisk placering

Syfte med gränsytan

Identifiering av informationen som är tänkt att utbytas vid gränsytan

Hur utbytet är tänkt att ske, med riktning

Referens till de komponenter i arkitekturbeskrivningen som utgör gränsytan

Referens till eventuella komponenter som är avsedda att skydda gränsytan eller kontrollera informationsutbytet.

Det är via gränsytorna som informationssystemet exponeras för personer, både fysiskt och logiskt. <Ange hur respektive gränsyta blir exponerad>

Fysiska externa gränsytor

<Beskriv informationssystemets fysiska externa gränsytor>

Logiska externa gränsytor

<Beskriv informationssystemets logiska externa gränsytor>

Avgränsning av ackrediteringsobjektet

För att tydliggöra vad som omfattas av denna ITSA och vad som behöver hanteras av driftmiljön, anges här avgränsning av informationssystemet (ackrediteringsobjektet).

Ett sätt att illustrera ackrediteringsobjektet är att beskriva tre zoner som ligger inuti varandra:

Innersta zonen - ackrediteringsobjektet

Innersta zonen innehåller det tekniska i informationssystemet som ska ackrediteras. Exempelvis programvara, operativsystem, datorhårdvara, nätverksutrustning, aktiva kort och brandväggar. Komponenter placerade i denna zon, som inte redan är godkända, kommer att kravställas och evalueras i ISD-arbetet.

Omgivningen

Zonen som omger ackrediteringsobjektet innehåller driftmiljön för informationssystemet. Exempelvis andra system med gränsytor till informationssystemet, entiteter som interagerar med informationssystemet, organisationer som äger/ansvarar/drift- och underhåller informationssystemet med alla dess instruktioner, manualer och rutinbeskrivningar. Ackrediteringsobjektet har ett beroende till denna driftmiljö tack vare att vissa informationssäkerhetskrav realiseras här eller på grund av interagerande system.

Utanför omgivningen

Yttersta zonen innehåller system, roller, organisation, rutiner m.m. som inte har någon påverkan eller interaktion med informationssystemet. Men det är lämpligt att förtydliga att dessa är avgränsade från ackrediteringsobjektet och dess omgivning

<Beskriv avgränsning av ackrediteringsobjektet>

Säkerhetsförmågor

Detta avsnitt sammanställer de säkerhetsförmågor som informationssystemet behöver realisera.

Medan systemarkitekturen beskriver informationssystemets uppbyggnad och vilka komponenter som ingår, beskrivs här de säkerhetsförmågor och säkerhetsfunktioner som det tillhandahåller. Säkerhetsförmågorna ska beskrivas på en detaljnivå som är tillräcklig för att ge läsaren en allmän förståelse.

<Lista informationssystemets säkerhetsförmågor>

Säkerhetsarkitektur

Detta kapitel beskriver och specificerar säkerhetsarkitekturen genom design av säkerhetsfunktioner. Här framgår vad säkerhetsfunktionerna ska göra, hur de ska fungera och var de ska realiseras.

Säkerhetsfunktionskedjor

Vissa säkerhetsfunktioner behöver designas med beroenden till flera andra informationssystem, både tekniska och administrativa, för att fungera. Dessa distribuerade säkerhetsfunktioner kan då sägas utgöra olika säkerhetsfunktionskedjor. Detta avsnitt beskriver sambandet mellan olika informationssystem som kommunicerar med varandra och tillsammans bildar säkerhetsfunktionskedjor.

Avsnitten nedan ger exempel på tre vanligt förekommande säkerhetsfunktionskedjor. För informationssystemet kan det även tillkomma fler funktionskedjor, t.ex övervakning. Dessa ska i så fall läggas till här.

Avsnitten ska endast förklara funktionskedjorna översiktligt då djupare förklaring kring säkerhetsfunktionerna ges i avsnitt 5.2.

Säkerhetsfunktionskedja för gemensam tid

I detta avsnitt beskrivs designen av säkerhetsfunktionskedjan för att åstadkomma säkerhetsfunktionen gemensam tid.

<Beskriv säkerhetsfunktionskedjan i ord och bild>

Säkerhetsfunktionskedja för behörighetskontroll

I detta avsnitt beskrivs designen av säkerhetsfunktionskedjan för att åstadkomma säkerhetsfunktionen behörighetskontroll.

<Beskriv säkerhetsfunktionskedjan i ord och bild>

Säkerhetsfunktionskedja för säkerhetsloggning

I detta avsnitt beskrivs designen av säkerhetsfunktionskedjan för att åstadkomma säkerhetsfunktionen säkerhetsloggning.

<Beskriv säkerhetsfunktionskedjan i ord och bild>

Säkerhetsfunktioner

Under följande avsnitt specificeras designen av respektive säkerhetsfunktion som informationssystemet ska realisera.

Designspecifikationen kan innehålla detaljer om vilka tekniska lösningar som ska användas i form av specifika programvaror och komponenter. Tänk i så fall på att endast specificera sådant som krävs för att säkerhetsarkitekturen ska bli säker. Det gäller att hålla informationen på rätt nivå för att undvika att låsa leverantörer till en enda lösning.

I nedan avsnitt ska det tydligt framkomma vilka delar av lösningen för säkerhetsfunktionen som ska implementeras internt i informationssystemet eller externt i driftmiljön.

Anpassa nedanstående avsnitt beroende på vilka säkerhetsfunktioner som ska finnas i informationssystemet.

Behörighetskontroll

I detta avsnitt specificeras designen av säkerhetsfunktionen för behörighetskontroll.

En del av lösningen för behörighetskontroll innebär specificering av vilka roller som informationssystemet ska hantera och vilka behörigheter dessa kräver. Denna specifikation utformas lämpligen i ett självständigt dokument (som kan kallas behörighetsmatris/Access Control Policy) då den möjligen kan återanvändas som en del av driftsdokumentationen.

De olika användningsfallen för behörighetskontroll i systemet ska också beskrivas.

<Specificera designlösningen>

Säkerhetsloggning

Detta avsnitt specificerar designen av säkerhetsfunktionen för säkerhetsloggning.

I detta avsnitt ska det framkomma vilka säkerhetsrelevanta händelser som ska loggas.

<Specificera designlösningen>

Intrångsskydd

Detta avsnitt specificerar designen av säkerhetsfunktionen för intrångsskydd.

<Specificera designlösningen>

Intrångsdetektering

Detta avsnitt specificerar designen av säkerhetsfunktionen för intrångsdetektering.

<Specificera designlösningen>

Skydd mot skadlig kod

Detta avsnitt specificerar designen av säkerhetsfunktionen för skydd mot skadlig kod.

<Specificera designlösningen>

Skydd mot obehörig avlyssning

Detta avsnitt specificerar designen av säkerhetsfunktionen för skydd mot obehörig avlyssning.

<Specificera designlösningen>

Skydd mot röjande signaler

Detta avsnitt specificerar designen av säkerhetsfunktionen för röjande signaler.

<Specificera designlösningen>

Integritetsskydd

Detta avsnitt specificerar designen av säkerhetsfunktionen för integritetsskydd.

<Specificera designlösningen>

Redundans och reserv

Detta avsnitt specificerar designen av säkerhetsfunktionen för redundans och reserv.

<Specificera designlösningen>

Säkerhetskopiering

Detta avsnitt specificerar designen av säkerhetsfunktionen för säkerhetskopiering.

<Specificera designlösningen>

Säker tid

Detta avsnitt specificerar designen av säkerhetsfunktionen för säker tid.

<Specificera designlösningen>

Säkert tillstånd

Detta avsnitt specificerar designen av säkerhetsfunktionen för säkert tillstånd.

<Specificera designlösningen>

kallas ofta behörighetsmatris (eng. Access Control Policy)