IT-SÄKERHETSARKITEKTUR EN VÄGLEDNING FÖR ELBRANSCHEN MED TYPEXEMPEL OCH REFERENSLÖSNINGAR

Transkript

1 IT-SÄKERHETSARKITEKTUR EN VÄGLEDNING FÖR ELBRANSCHEN MED TYPEXEMPEL OCH REFERENSLÖSNINGAR

2 Förord En väl fungerande elförsörjning är en nödvändig förutsättning för ett modernt samhälle. Företag verksamma inom elförsörjningen utsätts varje dag för olika slags angrepp. Det handlar om bl.a. inbrott och skadegörelse men också i ökande utsträckning om IT-angrepp. Eftersom nästan all informationshantering och processtyrning i dag sker med stöd av IT är det viktigt att svenska elföretag utformar sina IT-lösningar på ett säkerhetsmässigt bra sätt. Denna vägledning syftar till att stödja säkerhetsarbetet hos elföretagen i Sverige, så att risken för otillbörlig påverkan på kritiska system kan minimeras. Vägledningen ger exempel på hur en IT-arkitektur kan utformas för att uppnå en god säkerhetsnivå en IT-säkerhetsarkitektur. Min förhoppning är att vägledningen ska inspirera till utformning av robusta och säkra IT-lösningar. Den kan med fördel användas både i samband med utveckling av nya ITsystem och vid ändringar eller nyinstallationer där man vill skydda funktioner som är kritiska för verksamheten. Jag vill tacka alla som deltagit i arbetsgruppen, referensgruppen och övriga som lämnat värdefulla bidrag för att vägledningen ska bli ett praktiskt användbart hjälpmedel i det fortsatta säkerhetsarbetet. Sundbyberg i februari 2015 Mikael Odenberg Generaldirektör 1/120

3 2/120

4 Innehåll 1 Sammanfattning Dokumentets struktur Målgrupp Avgränsningar Arbetsform för framtagande av rapporten Bakgrund Definitioner Vad är en IT-arkitektur? Vad är en IT-säkerhetsarkitektur? Samband ledningssystem för informationssäkerhet och en säkerhetsarkitektur Sambandet IT-arkitektur och en säkerhetsarkitektur Sambandet säkerhetsarkitektur och informationsklassning Samband säkerhetsarkitektur och risk- och sårbarhetsanalys Behov Behov av uppfyllnad av formella krav Behov av att uppfylla organisationens säkerhetskrav Behov av effektivisering och rationalitet Behov av att skydda interna informationsresurser Behov av att skydda externa informationsresurser Skydd av informationsresurser som köps som tjänst av externa parter Krav Modeller Enterprise information security architecture TOGAF /120

5 4.3 Open Security Architecture SABSA Andra modeller, ramverk och ledningssystem LIS, ISO/IEC CSMS, IEC Jämförelser mellan modeller Tekniska lösningar Arkitekturkomponenter Tidssynkronisering Logginsamling och loggbearbetning Autentiseringstjänster Katalogtjänster Mjukvaruuppdateringar Övervakning, larm och uppföljning Nätverkssäkerhet Nättopologiska säkerhetsfunktioner Nätverkskrypteringslösningar Fjärråtkomst Nätverksmässig zonindelning Identitetshantering och behörighetskontroll Lösenord och lösenordsfraser System baserade på publika nyckellösningar, PKI Avancerade och federerade identitetstjänster Skydd av information Krypteringslösningar för överförd information Krypteringslösningar för sparad information Andra säkerhetskontroller Icke-tekniska lösningar Inventering av informationstillgångar Klassning av information Risk- och sårbarhetsanalys Säkerhetsanalys Säkerhetsgranskningar /120

6 6.5.1 Säkerhetstester Implementationsfrågor SOC, security operations centre Vanliga problem och utmatningar Problem med skydd mot skadlig kod Problem med nätverksmässig åtkomstkontroll Problem med patchhantering Problem med PKI och certifikathantering Problem med brandväggar Problem med zonmodeller Problem med testning Problem med loggning, logghantering och spårdata Problem med hantering av komponenter utan egen säkerhet Översikt över IT-funktioner som finns i ett elföretag Referensarkitekturer Allmän översikt Referensmodell med uppdelat nät Typfall för fjärråtkomst Open Security Architecture Open Security Architectures generella modellösning Open Security Architectures modellösning för serversäkerhet Open Security Architectures modellösning för en brandvägg med DMZ Open Security Architectures modellösning för industriella kontrollsystem Open Security Architectures modellösning för avancerad övervakning och detektering IEC /120

7 10 Uppslagsord Referenser Sakregister /120

8 Lista över figurer Figur 1 Beskrivning metamodell som förklarar relationen mellan säkerhetsarkitektur och andra storheter Figur 2 Översiktligt landskarta...17 Figur 3 Översiktsbild som beskriver allmänt hur arkitekturer inom verksamhet, information och teknik förhåller sig till varandra Figur 4 Lanskapsöversikt säkerhetsarkiktektur, enligt OSA Figur 5 Översiktsbild av SABSA-ramverket Figur 6 Översiktsbild av tidsserver uppsatt så att denne skickar synkroniseringsmeddelanden till via nätverket Figur 7 Översiktsbild av loggserver uppsatt så att andra servrar skickar loggar och spårdata via nätverket Figur 8 Översiktsbild av larm- och övervakningserver uppsatt så att andra servrar skickar larm via nätverket Figur 9 principbild av hur en brandvägg fungerar Figur 10 brandväggsbild Figur 11 brandväggsbild som visar en brandvägg som används internt i organisationen för att skilja mellan koncernnätet och känsliga nätverk, i detta fall ett processkontrollnätverk Figur 12 Översiktsbild åtkomstkontroll på nätverksnivå Figur 13 Översiktsbild över nätbaserade intrångsdetekteringssystem Figur 14 Översiktsbild över nätbaserade intrångspreventeringssystem Figur 15 Översiktsbild av VPN-lösning Figur 16 Översiktsbild av VPN-lösning där kryptotunneln är etablerad Figur 17 Översiktsbild av VPN-lösning där kryptotunneln är etablerad mellan klient med VPN-programvara och en VPN-gateway Figur 18 Översikt av en koncentrisk zonmodell Figur 19 Översikt av en koncentrisk zonmodell Figur 20 Översikt av Burtons zonmodell Figur 21 Översikt av zonmodell där även regelverket för informationutbyte mellan zoner beskrivs Figur 22 Översikt av PKI-lösning Figur 23 Översikt uppdelning av nätverk och interna skydd i form av brandväggar Figur 24 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar Figur 25 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar Figur 26 Översiktsbild generell modellösning Figur 27 Översiktsbild modellösning för serversäkerhet /120

9 Figur 28 Översiktsbild modellösning DMZ Figur 29 Översiktsbild modellösning för industriella kontrollsystem Figur 30 Översikt av typmodellen för avancerad övervakning och monitorering /120

10 1 Sammanfattning Att samhällsviktiga funktioner, såsom elförsörjning, är potentiella mål för olika typer av angripare är inget som någon idag ifrågasätter eller har anledning att ifrågasätta. Vid en väpnad konflikt är attacker mot infrastruktur ett sätt att skada sin fiende, ofta med vapenmakt. Vid många andra typer av konflikter kan alternativ till väpnade attacker eller fysiska angrepp vara en lyckad väg framåt uppdagade det sig för världen att IT-angrepp mot industriella kontrollsystem med hjälp av den skadliga koden Stuxnet 1 hade varit framgångsrikt. Detta visar på sårbarheten i våra kritiska system och den typ av system som utgör våra samhällsviktiga funktioner. Sårbarheterna måste åtgärdas och någon typ av skyddsfunktioner och säkerhetskontroller måste etableras. För att uppnå en viss nivå av grundskydd i sin IT-miljö och det ekosystem av infrastruktur, system och applikationer denna miljö utgör, så måste varje organisation ha ett systematiskt säkerhetsarbete som inför och underhåller genomtänkta säkerhetsmekanismer. Detta arbete med grundskyddet kan anses utgöra en ITsäkerhetsarkitektur, kan ses som konstruktionsritningar som beskriver de bärande fundament och kritiska element som skall stötta resten av byggnaden i detta fall övriga IT-arkitekturen. Olika typer av konstruktionsritningar beskriver konceptuella, operationella, fysiska och logiska sammanhang av IT-säkerhetsarkitekturen. Målet med att ta fram denna vägledning är att kunna ge elföretagen i Sverige en verktygslåda, exempelsamling och inspirationskälla att ta del av. Den skall ge grundläggande förståelse och kunskaper om skyddsbehov, vanliga skyddsmekanismer och säkerhetslösningar för att skydda sin information och sin IT-miljö. Vägledningen kan med fördel användas innan man bygger en IT-miljö. Den kan också användas som referens när det sker ändringar, tillägg och nyinstallationer. Förutom de rent tekniska lösningarna för skyddsmekanismer så måste en säkerhetsarkitektur även innehålla väl utvecklade funktioner för löpande underhåll och förvaltning. Detta inkluderar processer, rutiner, roller med mera för att skapa lösningar för att uppgradera eller uppdatera programvara som har säkerhetsproblem, kunna hantera säkerhetskopiering, utföra löpande övervakning och detektering med mera. 1 MSB Stuxnet IT som vapen eller påtryckningsmedel 9/120

11 Denna text beskriver såväl teknik som de andra aspekterna. Förhoppningen är att denna uppställning och övergripande beskrivning ger en god inblick i vad det innebär att ha en god säkerhetsarkitektur på plats. Det är viktigt att lägga fast att denna vägledning beskriver säkerhetsarkitekturens tre huvudsakliga beståndsdelar med IT-landskap, mönsterkatalog och en katalog med säkerhetskontroller. IT-landskapet får vara ett idealiserat exempellandskap. Dokumentet har en begränsad mönsterkatalog där några typfall finns beskrivna. Läsarna måste sedan för att skapa en säkerhetsarkitektur själva arbeta vidare med att vidareutveckla mönsterkataloger och kataloger med säkerhetskontroller för att anpassa till sitt IT-landskap och sina förutsättningar. 10/120

12 2 Dokumentets struktur Dokumentet består av flera delar. En inledande allmän del beskriver bakgrund, avgränsningar och allmänt om dokumentet. Dokumentet har också en mer teknisk del där IT- och informationssäkerhetsarkitekturer samt de olika komponenter som utgör dessa beskrivs närmare. Senare delen av vägledningen har olika typexempel, där olika tekniska, administrativa och organisatoriska säkerhetskontroller sätts i ett sammanhang. Då dokumentet innehåller en mängd fackord, så har det försätts med en omfattande ordlista för att underlätta för läsaren. Ordlistan finns i slutet på dokumentet. En referenslista med listningar av olika dokument, standarder, webbplatser mm finns i senare delen av dokumentet. I slutet av dokumentet finns ett sakregister som underlättar för läsaren att hitta information efter nyckelord, uppslagsord eller begrepp som används i vägledningen. 2.1 Målgrupp Målgrupperna för denna vägledning är säkerhetsansvariga, säkerhetsskyddschefer, ITchefer, IT-ansvariga, systemutvecklare, nätverksansvariga och projektledare inom ITområdet. Andra som arbetar med säkerhetsfrågor, IT-området eller processkontroll har också nytta av vägledningen. 2.2 Avgränsningar Dokumentet är avsett att ge en första bred överblick. Därmed är det inte en fördjupning inom vart och ett av de områden eller teknologier som beskrivs, då det i så fall snarare hade blivit en lärobok inom hela området IT- och informationssäkerhet. Inte heller sätter detta dokument några specifika nivåer på de krav som ställs. Detta är något som organisationen och dess företrädare själva måste göra med stöd av exempelvis utfallet från tillämpliga riskanalyser. I dokumentet kan en säkerhetskomponent, exempelvis en brandvägg, beskrivas, men det är läsaren utifrån sina behov, som själv måste bestämma hur denna brandvägg skall vara uppsatt och med vilka inställningar denna brandvägg skall konfigureras. 11/120

13 2.3 Arbetsform för framtagande av rapporten Rapporten är framtagen av Svenska kraftnät. Till arbetet har även MSB, Vattenfall och E.on bidragit. Huvudförfattare är Robert Malmgren. 12/120

14 3 Bakgrund Detta kapitel beskriver bakgrunden och behoven till varför en organisation behöver en IT-säkerhetsarkitektur. Kapitlet ger också en grundförståelse genom att definiera basbegrepp såsom IT-arkitektur och IT-säkerhetsarkitektur samt hur dessa relaterar till andra viktiga säkerhetskoncept. 3.1 Definitioner För att ge en bra förståelse för denna text, ges här en grundläggande introduktion till några centrala begrepp som är viktiga att förstå betydelsen av. Texten brukar även en massa andra facktermer och begrepp, vilka finns definierade i slutet av vägledningen Vad är en IT-arkitektur? En IT-arkitektur är ett metodiskt och systematiskt sätt att beskriva koncept, tekniker och modeller inom IT för att på så sätt skapa ett sammanhållande ramverk för applikationer, infrastruktur, säkerhet med mera. IT-arkitekturen, eller Enterprise Architecture, EA, som detta numera kallas, är ett sätt att organisera verksamhetsprocesser och IT-infrastruktur för att skapa (tekniska och andra) standarder och effektiva arbetssätt som går i linje med affärsstrategier, affärsmodeller och verksamhetens övergripande styrning Vad är en IT-säkerhetsarkitektur? En IT-säkerhetsarkitektur kan ses vara ett ramverk på strategisk nivå som innehåller koncept, styrande säkerhetsprinciper och en gemensam struktur för var, när och hur säkerhetsfunktioner och skyddsmekanismer införs och hur de skall förvaltas och hanteras. Denna IT-säkerhetsarkitektur är också relaterad till IT-arkitekturen så att dessa skyddsmekanismer, koncept med mera placeras på rätt ställe. Skyddsmekanismerna och säkerhetskontrollernas syfte i säkerhetsarkitekturen är att upprätthålla beslutade skyddsnivåer avseende sekretess, riktighet, tillgänglighet samt spårbarhet för den information som finns i organisationen och den IT-miljö som nyttjas. Bland de byggklossar som formar organisationens säkerhetsarkitektur finns, bland annat: > Behörighetsmodeller och behörighetssystem > Klassningsmodeller av system och information > Skydd på nätverksnivå, nättopologi, segmentering och zonmodeller 13/120

15 > Systemsäkerhet i form av processer för uppdateringar, härdning, formella säkerhetsmodeller ed mera. > Applikationssäkerhet i form av anpassade utvecklingsprocesser som även inkluderar säker programutveckling och säkerhetstestning > Loggning, larm och spårdata Dessa byggklossar består i praktiken ofta av säkerhetsprodukter eller olika tekniska arrangemang och lösningar, arrangerade på ett sådant sätt att dessa passar den egna organisationen och dess verksamhet på ett effektivt sätt. Mer konkret är säkerhetsarkitekturens byggklossar utformade från många enkla och raka säkerhetsprinciper såsom: > Försvar i djupled (eng. defense in depth) > Varierat skydd (eng. diversity of protection) > Lägsta privilegienivå (eng. least privilege) > Skydd vid källan (eng. protection at source) > Begränsningspunkter (eng. choke points) > Säkert tillstånd vid fel (eng. fail-safe) > Spårbarhet i varje steg av hanteringen Genom att skapa en övergripande säkerhetsarkitektur som utifrån dessa typer av enkla principer bygger tekniska skydd, utformar drift- rutiner eller processer, så går det att skapa en systematisk och strukturerad säkerhet i IT-landskapet, dess olika komponenter och användningsområden. Bilden Figur 1- nedan beskriver en relationsmodell och visar grafiskt på en översiktsnivå hur de olika begreppen relaterar till varandra och vad de ger för någon effekt. Bilden kan vid första anblicken framstå som komplex och kräver lite längre tid och en viss arbetsinsats för att tränga in i och förstå. Om man tar sig den tiden, så har man skapat sig en klar förståelse på de bärande tankarna, grundkoncepten, termerna och principerna. 14/120

16 Figur 1 Beskrivning metamodell som förklarar relationen mellan säkerhetsarkitektur och andra storheter Säkerhetskontroller, ibland kallade skyddsmekanismer eller säkerhetsfunktioner, är centrala begrepp för de tekniska skydden. Säkerhetsarkitekturens verktygslåda består av en katalog av färdiga säkerhetskontroller vilka kan användas alltefter behov och skyddsvärde på informationen. Säkerhetsarkitekturen omfattar olika huvudsakliga kategorier i form av: > IT-landskap eller IT-miljö, ofta beskriven i form av en landskapskarta > En mönsterkatalog > En katalog med olika säkerhetskontroller Arbetet med säkerhetsarkitekturen kan också innebära framtagandet av en hotkatalog, mot vilka säkerhetskontrollerna matchas och stäms av. Hotkatalogen är en systematisk samling som listar många upptänkliga hot som kan uppstå. 15/120

17 Denna vägledning beskriver de tre första delarna. Vägledningen har en mer utförlig katalog över säkerhetskontroller samt en begränsad mönsterkatalog där några typfall finns beskrivna. Läsarna måste sedan för att skapa en säkerhetsarkitektur själva arbeta vidare med att vidareutveckla mönsterkataloger och kataloger med säkerhetskontroller för att anpassa till sitt IT-landskap och sina förutsättningar. För en hotkatalog, mot vilka säkerhetskontroller kan stämmas av, se Svenska kraftnäts hotkatalog för elbranschen /120

18 Figur 2 Översiktligt landskarta Organisationens katalog med de av organisationen utvalda och godkända säkerhetskontrollerna är en central del av själva säkerhetsarkitekturen. Kontrollerna är sättet att översätta organisationens olika krav och policys till verkliga skyddsåtgärder som går 17/120

19 att använda inom organisationens olika skyddsmönster. Genom att ha en standardiserad uppsättning typkontroller kan dessa snabbt matchas mot de olika krav och behov som organisationen uppvisar Samband ledningssystem för informationssäkerhet och en säkerhetsarkitektur Ett ledningssystem för informationssäkerhet, allmänt kallat LIS, är ett sätt att etablera och systematiskt driva säkerhetsfrågorna med förankring hos organisationens ledning och personal. Ett LIS införs genom att skapa policys och processer samt arbetsformer och roller för att styra säkerhetsarbetet. Ett LIS och en säkerhetsarkitektur samexisterar och kompletterar varandra: > Ett LIS är den övergripande systematiken som svarar för vad som skall göras > En säkerhetsarkitektur svarar för hur det skall göras Sambandet IT-arkitektur och en säkerhetsarkitektur IT-arkitekturen, ibland kallad enterprise architecture eller dess förkortning EA, lägger grunden för de lösningsprinciper som organisationen använder för att skapa sitt ITlandskap och sina verksamhetssystem. För att få in säkerhet i denna IT-arkitektur så bör den följa en säkerhetsarkitektur som sätter upp ett regelverk för hur olika lösningar skall vara beskaffade ur ett säkerhetsperspektiv. En säkerhetsarkitektur är således något som såväl bestämmer ingångsvärden och sätter förutsättningar för ITarkitekturen såväl som att den bestämmer ett antal inskränkningar och avgränsningar Sambandet säkerhetsarkitektur och informationsklassning Andra viktiga koncept inom informationssäkerhet är klassning av information och system. Informationsklassning, på engelska kallat information asset classification, IAC, är ett sätt att bestämma informationens värde utifrån organisationens perspektiv. Informationsklassning är ofta baserat på informationens behov av konfidentialitet (skydd mot obehörig åtkomst), tillgänglighet eller dataintegritet. En säkerhetsarkitektur är naturligt knuten till organisationens informationsklassningsmodell. Det faller sig ganska naturligt att informationsklassning kan sättas i relation till säkerhetsarkitekturen genom att skapa olika säkerhetskontroller som sätts i relation till informationsklasser och nivåer av dessa klasser. Beroende på vilka krav som ställs på informationen, exempelvis höga krav på sekretess eller dataintegritet, kan olika kontroller och olika nivåer av dessa kontroller tillämpas i de fall en viss informationstyp används eller på annat vis hanteras. 18/120

20 3.1.6 Samband säkerhetsarkitektur och risk- och sårbarhetsanalys Säkerhetsarkitekturen innefattar ett antal viktiga byggklossar som ska kunna användas för att bygga säkerhetskontroller och skydd mot de hot som framkommer vid risk-, sårbarhets- eller säkerhetsanalys. Beroende på vilka risker som framkommer kan skydden behöva dimensioneras och hanteras olika. 3.2 Behov Nedan beskrivs allmänt några av de säkerhetsbehov som de flesta moderna organisationer har Behov av uppfyllnad av formella krav Inom vissa organisationer kan det finnas vissa formella krav på IT- och informationssäkerheten. Inom Sverige så finns det exempelvis vissa lagar och förordningar som påverkar att man måste ha IT-säkerhet och skydd av information och informationshanterande utrustning. Ett par exempel finns i bl.a. 31 tekniska och organisatoriska åtgärder i PuL, personuppgiftslagen (1998:204), eller i säkerhetsskyddslagen (1996:627). Andra exempel på branschkrav eller andra externa krav är internationella atomenergiorganet IAEA:s säkerhetskrav på IT-säkerhet i kärntekniska anläggningar Behov av att uppfylla organisationens säkerhetskrav För att uppfylla säkerhetskrav på informationshantering så behöver informationssäkerhet och IT-säkerhet finnas på plats. Detta sker i form av olika tekniska, organisatoriska och administrativa lösningar. Ofta finns dessa krav, lösningar och lösningsbeskrivningar dokumenterade inom en organisation. Kraven finns ibland nedbrutna och beskrivna i form av tekniska säkerhetslösningar. Ibland så har man inom en organisation standardiserat de olika tekniska säkerhetsmekanismerna och säkerhetslösningarna. Trots denna standardisering så är det inte sällan så att det finns en mängd olika lösningar vilka kommer från olika leverantörer, har olika kvalitet, kräver olika typer av underhåll och teknisk förvaltning Behov av effektivisering och rationalitet Ett annat behov är att rationalisera i floran av olika säkerhetslösningar som finns i en IT-miljö. Genom att införa en IT-säkerhetsarkitektur som standardiserar säkerheten så resulterar detta i en enhetlig miljö och därmed färre antal lösningar och funktioner vilket i sin tur leder till att det blir det lättare att förvalta organisationens säkerhetslösningar och säkerhetsmekanismer. 19/120

21 En viktig anledning till att ha en säkerhetsarkitektur med tillhörande katalog över säkerhetskontroller och mönster är att ha färdiga koncept och tekniska skydd, så att man slipper uppfinna hjulet varje gång organisationen skall göra en ny IT-lösning Behov av att skydda interna informationsresurser Det finns en mängd olika delar som informationen och bearbetningen av informationen skall skyddas mot bland annat: > Skydd mot obehörig åtkomst, > Skydd mot störningar, driftstopp > Skydd mot informationsförlust > Skydd mot manipulation av information > Skydd mot manipulation av system eller programvara Behov av att skydda externa informationsresurser Det blir allt vanligare att företag inte bara sköter sin IT internt utan att man på olika sätt lägger ut drift, köper in enstaka tjänster eller köper in hela områden (såsom nätverk och driftövervakning) som hanteras av tredje part. Några exempel på externa informationsresurser inkluderar: > XaaS (X as a service, där X exempelvis kan vara någon av nedanstående) PaaS Platform as a Service IaaS Infrastucture as a Service SaaS System as a Service BaaS Backup as a Service > Molntjänster > Projektplatser Det finns en inbyggd svårighet att helt kontrollera eller bestämma över typ av skydd, säkerhetsnivåer eller andra kvaliteter när tjänster och IT-resurser köps in i form av tjänster. Samtidigt som detta är en av poängerna med utläggning, att man delar resurser och skall uppnå olika typer av skalfördelar, så innebär det samtidigt att man har liten eller ingen insyn eller påverkan av säkerhet eller av skyddens reella utformning hos externa leverantörer av tjänsterna. 20/120

22 En IT-säkerhetsarkitektur bör i så stor utsträckning som möjligt innehålla koncept, principer och tankar som involverar även utlagd drift eller inköp av tjänster från tredje part. Detta gäller inte minst de delar som omfattar integration, informationsutbyte eller kopplingar mellan interna och externa IT-funktioner Skydd av informationsresurser som köps som tjänst av externa parter När alltmer IT-funktioner och IT-tjänster köps in och nyttjas som tjänster levererade över Internet av tredje part så behövs det ett annat tankesätt och förhållningssätt till säkerhetsfrågorna. Några exempel på sådana tjänster är moln-varianter av klassiska IT-leveranser och när vi mer och mer väljer XaaS-varianter (X as a Service). I en sådan situation finns inte längre det skydd som traditionellt utgör första linjen, det fysiska skyddet såsom exempelvis områdesskydd och skalskydd under egen kontroll. Det finns inget som omsluter och är ett heltäckande skydd. Så för att lösa detta nyuppkomna läge, där såväl information och informationsbehandlingsfunktioner i större utsträckning är under någon annans kontroll, så måste nya koncept, modeller och lösningar tas fram. Det finns olika forskningsdokument och koncept presenterade om detta sedan länge3. Det är viktigt att på principnivå att skilja på när en organisation använder en molntjänst, t.ex. kör programvara eller system i molnet som en strategi för företaget, jämfört med när en enskild medarbetare använder molnet av bekvämlighetsskäl (typ Dropbox eller icloud). Vem ansvarar för att t.ex. upphovsrättslagstiftning, PuL eller andra krav uppfylls i dessa fall? Även om styrningen och strategipåverkan är olika i de båda fallen så är det viktigt att riktlinjer är kända och följs då de även gäller för enskild användning. 3.3 Krav Vanliga krav som måste hanteras i en säkerhetsarkitektur inkluderar: > Spårbarhet > Skydd av obehörig åtkomst > Skydd mot förlust av data > Säkerhetskopiering och återställande av data /120

23 De säkerhetskontroller som beskrivs senare i denna vägledning ger exempel på när dessa krav har matchats med en teknisk lösning för att uppfylla kraven. 22/120

24 4 Modeller Detta kapitel beskriver olika arkitekturer och säkerhetsarkitekturer samt ger en överblick över dessa. Denna bakgrundsinformation är bra att ha när vi senare presenterar typfall. I detta kapitel beskrivs ett antal olika IT-arkitekturer och säkerhetsarkitekturer som har bäring för den övriga diskussionen och som har koppling till katalogen av säkerhetskontroller och till de referens- och exempelfall som ges i slutet av dokumentet. Detta kapitel är främst med som ett referenskapitel för att kunna ge läsaren en förståelse i hur de olika arkitekturer och ramverk som ofta används kan förhålla sig till, eller användas i, säkerhetsarkitekturen. Flera av dessa modeller har olika sätt att korrelera hur verksamhet, teknisk arkitektur och informationsarkitekturer förhåller sig till varandra. Nedanstående generella bild ger en allmän förståelse för ett enkelt och översiktligt sätt att se på detta. Notera att säkerhet är ett behov som finns inom alla de tre olika delarna. Figur 3 Översiktsbild som beskriver allmänt hur arkitekturer inom verksamhet, information och teknik förhåller sig till varandra 23/120

25 4.1 Enterprise information security architecture Analysföretaget Gartner föreslog integrerandet av säkerhetsfrågorna i de processer för Enterprise Architecture som började tas fram i stora organisationer i ett av sina s.k. research papers 4 Incorporating Security Into the Enterprise Architecture Process år Gartner har vidare arbetat med dessa koncept 5 och ramverk. Iden med EISA 6 är att knyta säkerhetsarbetet närmare de principer och koncept som används inom Enterprise Architecture, EA, samt att få till ett mer strategiskt fokus på detta säkerhetsarbete. Med BITS, Business Architecture, Information Architecture, Technology Architecture och Security Architecture, så är tanken med EISA att kunna vara det formella ramverket som skavara sammanhållande av de andra arkitekturella delarna och elementen. 4.2 TOGAF The Open Group Architectural Framework, TOGAF, är namnet på en välkänd Enterprise-arkitektur som började utvecklas i mitten av 1990-talet. TOGAF som sådant är versionsnumrerat. Den senaste version när denna vägledning skrivs är TOGAF 9. Bakom TOGAF står the Open Group, ett consortium som består av mer än 400 medlemsorganisationer. Open Group arbetar med att ta fram leverantörsneutrala standarder inom IT-området. TOGAF är en allmän arkitektur som modellerar hela organisationen och verksamheten. Eftersom TOGAF är så allmän och bred så har den inslag av säkerhet men det är inte en ren säkerhetsarkitektur, inte heller en ren IT-arkitektur. TOGAF är inte en öppen och allmänt tillgänglig standard, utan licensieras från OpenGroup-konsortiet. 4.3 Open Security Architecture Open Security Architecture, OSA 7, är ett allmänt tillgänglig och öppet ramverk för IToch informationssäkerhetsarkitektur. Bakom ramverket står en icke-vinstdrivande organisation med fritt medlemskap /120

26 I detta dokument så har vi använt OSA som en grund som vi utgår ifrån när vi senare i dokumentet visar på olika exempel- och referenslösningar. Valet är gjort på grund av att OSA är allmänt tillgängligt, och därmed har större möjlighet att nå ut, jämfört med andra arkitekturer som är leverantörsspecifika eller som kostar pengar för att nyttja. Nedanstående bild är en översikt av landskapet i OSA som beskriver de olika användningsfall och breda områden som utgör arkitekturen. 25/120