Upload
buikhuong
View
223
Download
0
Embed Size (px)
Citation preview
IT-SÄKERHETSARKITEKTUR EN VÄGLEDNING FÖR ELBRANSCHEN
MED TYPEXEMPEL OCH REFERENSLÖSNINGAR
2015-03-15
1/120
Förord
En väl fungerande elförsörjning är en nödvändig förutsättning för ett modernt sam-
hälle. Företag verksamma inom elförsörjningen utsätts varje dag för olika slags an-
grepp. 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äs-
sigt 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 IT-
system 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äm-
nat 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
3/120
Innehåll
1 Sammanfattning ........................................................................................................ 9
2 Dokumentets struktur ............................................................................................. 11
2.1 Målgrupp .................................................................................................... 11
2.2 Avgränsningar ........................................................................................... 11
2.3 Arbetsform för framtagande av rapporten ............................................. 12
3 Bakgrund ................................................................................................................. 13
3.1 Definitioner ................................................................................................ 13
3.1.1 Vad är en IT-arkitektur? ............................................................ 13
3.1.2 Vad är en IT-säkerhetsarkitektur? ............................................ 13
3.1.3 Samband ledningssystem för informationssäkerhet och en
säkerhetsarkitektur ..................................................................... 18
3.1.4 Sambandet IT-arkitektur och en säkerhetsarkitektur ............. 18
3.1.5 Sambandet säkerhetsarkitektur och informationsklassning... 18
3.1.6 Samband säkerhetsarkitektur och risk- och
sårbarhetsanalys ........................................................................ 19
3.2 Behov .......................................................................................................... 19
3.2.1 Behov av uppfyllnad av formella krav ...................................... 19
3.2.2 Behov av att uppfylla organisationens säkerhetskrav............. 19
3.2.3 Behov av effektivisering och rationalitet................................... 19
3.2.4 Behov av att skydda interna informationsresurser ................ 20
3.2.5 Behov av att skydda externa informationsresurser ................ 20
3.2.6 Skydd av informationsresurser som köps som tjänst av
externa parter ............................................................................. 21
3.3 Krav ............................................................................................................ 21
4 Modeller ...................................................................................................................23
4.1 Enterprise information security architecture ........................................ 24
4.2 TOGAF ....................................................................................................... 24
4/120
4.3 Open Security Architecture ...................................................................... 24
4.4 SABSA ......................................................................................................... 27
4.5 Andra modeller, ramverk och ledningssystem ....................................... 28
4.5.1 LIS, ISO/IEC-27000 ................................................................... 28
4.5.2 CSMS, IEC 62443 ....................................................................... 28
4.6 Jämförelser mellan modeller ................................................................... 28
5 Tekniska lösningar ................................................................................................. 29
5.1 Arkitekturkomponenter ............................................................................ 29
5.1.1 Tidssynkronisering .................................................................... 30
5.1.2 Logginsamling och loggbearbetning .........................................32
5.1.3 Autentiseringstjänster ................................................................34
5.1.4 Katalogtjänster ...........................................................................34
5.1.5 Mjukvaruuppdateringar ............................................................ 35
5.2 Övervakning, larm och uppföljning ......................................................... 35
5.3 Nätverkssäkerhet ...................................................................................... 38
5.3.1 Nättopologiska säkerhetsfunktioner ........................................ 38
5.3.2 Nätverkskrypteringslösningar ................................................. 46
5.3.3 Fjärråtkomst ............................................................................... 51
5.3.4 Nätverksmässig zonindelning .................................................... 52
5.4 Identitetshantering och behörighetskontroll ........................................... 57
5.4.1 Lösenord och lösenordsfraser .................................................... 57
5.4.2 System baserade på publika nyckellösningar, PKI .................. 57
5.4.3 Avancerade och federerade identitetstjänster ......................... 58
5.5 Skydd av information ................................................................................ 59
5.5.1 Krypteringslösningar för överförd information ...................... 59
5.5.2 Krypteringslösningar för sparad information ......................... 59
5.6 Andra säkerhetskontroller ....................................................................... 60
6 Icke-tekniska lösningar .......................................................................................... 60
6.1 Inventering av informationstillgångar ................................................... 61
6.2 Klassning av information.......................................................................... 61
6.3 Risk- och sårbarhetsanalys ....................................................................... 61
6.4 Säkerhetsanalys ........................................................................................ 62
6.5 Säkerhetsgranskningar ............................................................................ 62
5/120
6.5.1 Säkerhetstester ............................................................................63
7 Implementationsfrågor .......................................................................................... 64
7.1 SOC, security operations centre ............................................................... 64
7.2 Vanliga problem och utmatningar .......................................................... 64
7.2.1 Problem med skydd mot skadlig kod ........................................ 64
7.2.2 Problem med nätverksmässig åtkomstkontroll ........................ 65
7.2.3 Problem med patchhantering ................................................... 66
7.2.4 Problem med PKI och certifikathantering ............................... 66
7.2.5 Problem med brandväggar ........................................................ 67
7.2.6 Problem med zonmodeller ......................................................... 68
7.2.7 Problem med testning ................................................................. 71
7.2.8 Problem med loggning, logghantering och spårdata .............. 71
7.2.9 Problem med hantering av komponenter utan egen
säkerhet ........................................................................................ 72
8 Översikt över IT-funktioner som finns i ett elföretag ............................................ 74
9 Referensarkitekturer ............................................................................................... 79
9.1 Allmän översikt .......................................................................................... 79
9.1.1 Referensmodell med uppdelat nät ............................................. 79
9.1.2 Typfall för fjärråtkomst ............................................................. 81
9.2 Open Security Architecture ...................................................................... 85
9.2.1 Open Security Architectures generella modellösning ............. 86
9.2.2 Open Security Architectures modellösning för
serversäkerhet ............................................................................. 87
9.2.3 Open Security Architectures modellösning för en brandvägg
med DMZ .................................................................................... 92
9.2.4 Open Security Architectures modellösning för industriella
kontrollsystem ............................................................................. 95
9.2.5 Open Security Architectures modellösning för avancerad
övervakning och detektering ..................................................... 99
9.3 IEC 62443 ................................................................................................. 102
6/120
10 Uppslagsord ........................................................................................................... 104
11 Referenser .............................................................................................................. 113
12 Sakregister .............................................................................................................. 117
7/120
Lista över figurer Figur 1 Beskrivning metamodell som förklarar relationen mellan säkerhetsarkitektur och andra storheter ........................................................................................................... 15
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 ........................................................... 23
Figur 4 Lanskapsöversikt säkerhetsarkiktektur, enligt OSA .......................................... 26
Figur 5 Översiktsbild av SABSA-ramverket .................................................................... 27
Figur 6 Översiktsbild av tidsserver uppsatt så att denne skickar synkroniseringsmeddelanden till via nätverket .............................................................. 30
Figur 7 Översiktsbild av loggserver uppsatt så att andra servrar skickar loggar och spårdata via nätverket ...................................................................................................... 33
Figur 8 Översiktsbild av larm- och övervakningserver uppsatt så att andra servrar skickar larm via nätverket ................................................................................................ 37
Figur 9 principbild av hur en brandvägg fungerar .......................................................... 39
Figur 10 brandväggsbild ................................................................................................... 40
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 ..................................................................................................... 40
Figur 12 Översiktsbild åtkomstkontroll på nätverksnivå ................................................ 42
Figur 13 Översiktsbild över nätbaserade intrångsdetekteringssystem .......................... 44
Figur 14 Översiktsbild över nätbaserade intrångspreventeringssystem ........................ 45
Figur 15 Översiktsbild av VPN-lösning ............................................................................ 47
Figur 16 Översiktsbild av VPN-lösning där kryptotunneln är etablerad ....................... 48
Figur 17 Översiktsbild av VPN-lösning där kryptotunneln är etablerad mellan klient med VPN-programvara och en VPN-gateway ................................................................. 49
Figur 18 Översikt av en koncentrisk zonmodell .............................................................. 53
Figur 19 Översikt av en koncentrisk zonmodell .............................................................. 54
Figur 20 Översikt av Burtons zonmodell ......................................................................... 55
Figur 21 Översikt av zonmodell där även regelverket för informationutbyte mellan zoner beskrivs ................................................................................................................... 56
Figur 22 Översikt av PKI-lösning ..................................................................................... 58
Figur 23 Översikt uppdelning av nätverk och interna skydd i form av brandväggar ... 80
Figur 24 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar ............. 82
Figur 25 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar ............. 83
Figur 26 Översiktsbild generell modellösning ................................................................ 87
Figur 27 Översiktsbild modellösning för serversäkerhet ................................................ 88
8/120
Figur 28 Översiktsbild modellösning DMZ ..................................................................... 93
Figur 29 Översiktsbild modellösning för industriella kontrollsystem ........................... 96
Figur 30 Översikt av typmodellen för avancerad övervakning och monitorering....... 100
9/120
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 at-
tacker eller fysiska angrepp vara en lyckad väg framåt. 2010 uppdagade det sig för
världen att IT-angrepp mot industriella kontrollsystem med hjälp av den skadliga
koden Stuxnet1 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årbarheter-
na 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 infra-
struktur, 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äkerhets-
mekanismer. Detta arbete med grundskyddet kan anses utgöra en IT-
sä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 verk-
tygslåda, exempelsamling och inspirationskälla att ta del av. Den skall ge grundläg-
gande 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äkerhetsar-
kitektur även innehålla väl utvecklade funktioner för löpande underhåll och förvalt-
ning. 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 han-
tera säkerhetskopiering, utföra löpande övervakning och detektering med mera.
1 MSB Stuxnet – IT som vapen eller påtryckningsmedel https://www.msb.se/RibData/Filer/pdf/26068.pdf
10/120
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.
11/120
2 Dokumentets struktur
Dokumentet består av flera delar. En inledande allmän del beskriver bakgrund, av-
grä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 samman-
hang.
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 in-
formation 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, IT-
chefer, IT-ansvariga, systemutvecklare, nätverksansvariga och projektledare inom IT-
områ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ördjup-
ning 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 exem-
pelvis 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.
12/120
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.
13/120
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 bas-begrepp 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.
3.1.1 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 appli-
kationer, infrastruktur, säkerhet med mera. IT-arkitekturen, eller Enterprise Ar-
chitecture, EA, som detta numera kallas, är ett sätt att organisera verksamhetsproces-
ser 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 över-
gripande styrning.
3.1.2 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 han-
teras. 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 nytt-
jas.
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
14/120
> Systemsäkerhet i form av processer för uppdateringar, härdning, formella säker-
hetsmodeller ed mera.
> Applikationssäkerhet i form av anpassade utvecklingsprocesser som även inklude-
rar 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 komponen-
ter och användningsområden.
Bilden –Figur 1- nedan beskriver en relationsmodell och visar grafiskt på en översikts-
nivå 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.
15/120
Figur 1 Beskrivning metamodell som förklarar relationen mellan säkerhetsarkitektur och andra stor-heter
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å.
16/120
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 typ-
fall 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äker-
hetskontroller 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 elbranschen2.
2 http://www.energisakerhetsportalen.se/media/1040/Hotkatalog-fo%C2%A6%C3%AAr-Elbranschen-MASTER.pdf
17/120
Figur 2 Översiktligt landskarta
Organisationens katalog med de av organisationen utvalda och godkända säkerhets-
kontrollerna ä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
18/120
att använda inom organisationens olika skyddsmönster. Genom att ha en standardise-
rad uppsättning typkontroller kan dessa snabbt matchas mot de olika krav och behov
som organisationen uppvisar.
3.1.3 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 samexiste-
rar 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
3.1.4 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 IT-
landskap 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ösning-
ar 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 IT-
arkitekturen såväl som att den bestämmer ett antal inskränkningar och avgränsningar.
3.1.5 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 informationsklass-
ningsmodell. Det faller sig ganska naturligt att informationsklassning kan sättas i re-
lation 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 in-
formationstyp används eller på annat vis hanteras.
19/120
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 organisat-
ioner har.
3.2.1 Behov av uppfyllnad av formella krav
Inom vissa organisationer kan det finnas vissa formella krav på IT- och informations-
sä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 informations-
hanterande 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 atomenergi-
organet IAEA:s säkerhetskrav på IT-säkerhet i kärntekniska anläggningar.
3.2.2 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, organisato-
riska och administrativa lösningar. Ofta finns dessa krav, lösningar och lösningsbe-
skrivningar 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äkerhets-
mekanismerna 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.
3.2.3 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äkerhets-
lösningar och säkerhetsmekanismer.
20/120
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.
3.2.4 Behov av att skydda interna informationsresurser
Det finns en mängd olika delar som informationen och bearbetningen av information-
en 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
3.2.5 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ät-
verk 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 resur-
ser 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.
21/120
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.
3.2.6 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äck-
ning ä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 moln-
tjänst, t.ex. kör programvara eller system i molnet som en strategi för företaget, jäm-
fö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
3 https://collaboration.opengroup.org/jericho/presentations/fall2007/blum.pdf
22/120
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.
23/120
4 Modeller
Detta kapitel beskriver olika arkitekturer och säkerhetsarkitekturer samt ger en över-blick ö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äker-
hetskontroller 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
24/120
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 papers4 ”Incorporating Security Into the Enterprise Architecture Process” år
2006. Gartner har vidare arbetat med dessa koncept5 och ramverk.
Iden med EISA6 ä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 ramver-
ket 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 Enter-
prise-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 med-
lemsorganisationer. Open Group arbetar med att ta fram leverantörsneutrala standar-
der inom IT-området.
TOGAF är en allmän arkitektur som modellerar hela organisationen och verksamhet-
en. 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, OSA7, är ett allmänt tillgänglig och öppet ramverk för IT-
och informationssäkerhetsarkitektur. Bakom ramverket står en icke-vinstdrivande
organisation med fritt medlemskap.
4 https://www.gartner.com/doc/488575/incorporating-security-enterprise-architecture-process 5 http://gartnerinfo.com/futureofit2011/MEX38L_D2%20mex38l_d2.pdf 6 https://en.wikipedia.org/wiki/Enterprise_information_security_architecture
7 http://www.opensecurityarchitecture.org/
25/120
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änd-
ningsfall och breda områden som utgör arkitekturen.
26/120
Figur 4 Lanskapsöversikt säkerhetsarkiktektur, enligt OSA8
8 http://www.opensecurityarchitecture.org/cms/foundations/osa-landscape
27/120
4.4 SABSA En annan arkitektur och övergripande ramverk är Sherwood Applied Business Security
Architecture, SASBSA9. Detta är en övergripande modell som likt ett paraply kan ligga
över andra modeller. SABSA började utvecklas 1995 och har vidareutvecklats sedan
dess. Till skillnad från EISA och TOGAF så är SABSA öppet tillgänglig.
Tabellen nedan sammanställer SABSA:s paraplyvy där de på ena axeln sätter olika
arkitekturvyer och på den andra axeln sätter in storheter som vem, när, hur, med mera
något sker.
Figur 5 Översiktsbild av SABSA-ramverket
9 http://www.sabsa.org/
28/120
4.5 Andra modeller, ramverk och ledningssystem
4.5.1 LIS, ISO/IEC-27000
Ett av de vanligaste säkerhetsramverken som förekommer inom såväl näringsliv och
stat- och myndighetsvärlden är en ISO-standard för arbetet med säkerhet. ISO 27000-
serien är till för att etablera och förvalta ett ledningssystem för informationssäkerhet,
LIS. På engelska kallas LIS ofta för Information Security Management System, ISMS
En särskild anpassning av ISO/IEC 27000 för elbolag finns i standarden ISO/IEC
27019 kallad “Information security management guidelines based on ISO/IEC 27002
for process control systems specific to the energy utility industry”. Detta dokument är
en uttolkning av kraven i 27001 utifrån ett elbolagsperspektiv där man tagit hänsyn till
de speciella omständigheter det innebär att I verksamheten ha samhällskritisk verk-
samhet samt att man har speciella typer av utrustning och IT-stöd.
I Tyskland finns det långt gångna planer på att det skall bli lagkrav på att el- och gasfö-
retag följer, och är kompatibla med, ISO/IEC 27019.
4.5.2 CSMS, IEC 62443
IEC, som är ett internationellt standardiseringsorgan för teknisk standardisering, har
skapat ett tillägg eller en vidareutveckling av LIS,och dess engelska ISMS-variant,
genom att ta fram konceptet Cyber Security Management System, CSMS. Detta finns i
standardserien IEC 62443 som består av ett antal publicerade och ett antal planerade
standarder och tekniska rapporter. IEC 62443 kommer ur industristandarden ISA-
9910, utvecklad av organisationen International Society of Automation, ISA.
IEC 62443 gås igenom mer i detalj senare i detta dokument i kapitel ”IEC 62443” sid
102.
4.6 Jämförelser mellan modeller Det finns en del akademisk forskning och akademiska avhandlingar på området jämfö-
relser mellan säkerhetsramverk11. Vi kommer dock inte gå närmare in på dessa olika
modelljämförelser här.
10 https://www.isa.org/isa99/
11 http://ac.els-cdn.com/S1877050910004643/1-s2.0-S1877050910004643-main.pdf?_tid=b6c3845c-3cc8-11e4-9130-00000aacb361&acdnat=1410779528_8f608d03b9a5c0bce7da3bad81a3d346
29/120
5 Tekniska lösningar
Detta kapitel beskriver övergripande de tekniska skyddskomponenter och säkerhets-kontroller som utgör delar av kontrollkatalogen
I detta avsnitt kommer vi gå igenom olika tekniska lösningar som används i olika
kombinationer och utsträckning för att skapa ett grundskydd inom en organisation.
Förutom de lösningar som finns exemplifierade här så finns det ytterligare ett stort
antal lösningar, lite beroende på förutsättningar, tekniska vägval, etc. Se vidare någon
av de referenser som finns i slutet på dokumentet för att få uppslag till andra säker-
hetskontroller.
Senare i vägledningen beskrivs vanliga frågor och problem. Detta stycke bör läsas av
alla som ämnar implementera några av de typkontroller som beskrivs i det här kapitlet
då många standardproblem eller ”barnsjukdomar” listas där. Allt detta för att undvika
några klassiska misstag vid implementation eller att koncpetet/utrustningen/
programvaran faktiskt fungerar på ett annat på ett annat sätt än det som man tror eller
tror sig förstå vid ett första allmänt intryck.
5.1 Arkitekturkomponenter > Övervakning, larm och uppföljning
> Nätverkssäkerhetskomponenter
Brandväggar
VPN
Intrångsdetekteringssystem
Tidsservrar
Loggservrar
Autentiseringstjänster
Katalogtjänster
> Mjukvaruuppdateringar
uppdateringsservrar
30/120
5.1.1 Tidssynkronisering
En viktig funktionalitet i alla säkerhetssammanhang är tid och tidshållning. Tid an-
vänds av vissa säkerhetsfunktioner såsom exempelvis behörighetskontrollsfunktioner
för att se ifall en användare har vissa behörigheter vid ett visst tillfälle. Tid används
också vid exempelvis skrivande av spårdata och loggar.
Det är mot bakgrund av ovanstående exempel viktigt att komponenter i en IT-
säkerhetsarkitektur har en synkroniserad tid. Det vill säga att man har en gemensam
tidsuppfattning och att denna tidsuppfattning är korrekt. Ett av de vanligaste sätten i
moderna IT-lösningar att synkronisera tid är att använda protokollet NTP, network
time protocol, för att överföra tidsinformation mellan datorer.
Figur 6 Översiktsbild av tidsserver uppsatt så att denne skickar synkroniseringsmeddelanden till via nätverket
Vikten av att ha korrekt tid i all utrustning kan inte överdrivas. Förutom att många
funktioner kräver rätt tid för att fungera korrekt, så underlättas felsökning och IT-
incidentutredningar i de fall då man måste gå igenom krashdumpar, debuggutskrifter,
loggar och spårdata om de tidsangivelser som ges i dessa är korrekta. Detta är särskilt
viktigt då man ofta måste ”lägga pussel” med denna typ av spår från flera olika system
och komponenter.
31/120
Det finns många andra problem inom hantering av tid såsom:
> Förekomsten av tidszoner
> Tidsomställning för sommar- och vintertid
> Att det är svårt att välja bra tidskällor
> Att vissa system glöms bort och inte omfattas av tidssynkroniseringsupplägget
> Att de klockor som finns inbyggda i datorer och annan utrustning är av dålig kvali-
tet och har en tendens att dra sig mycket
> Att olika system och applikationer är beroende av olika noggrannhet när det gäller
tidsangivelsens upplösning
Dessa saker kommer inte närmare avhandlas i denna vägledning men är något som
läsaren kan behöva ta hänsyn till när man inför en hantering av tidstjänster och tids-
synkronisering.
Rekommendation
Eftersom korrekt och synkroniserad tid är en viktig aspekt i många delar av både IT, IT-
säkerhet och i många fall även i verksamheten så är det viktigt att man använder tidssyn-
kroniseringsmekanismer för att sätta korrekt och synkroniserad tid i infrastrukturutrust-
ning, servrar och i applikationer.
Vissa tillämpningar, såsom skyddsfunktioner i elsystemet, kräver noggrann upplösning på
tidsangivelsen till bråkdelar av en sekund, varpå det är viktigt att man har rätt typ av tids-
källor och tidshantering.
För mer information om tidssynkronisering, se MSBs rapport ” Vikten av var och när-
Samhällets beroende av korrekt tids- och positionsangivelse”12
Tidgivning i olika nät och olika zoner är också viktig. Hur man distribuerar tid och
synkroniserar tid mellan olika nätsegment och nätzoner är tekniska frågor och strate-
gier som måste hanteras i en IT-miljö med zonmodellen implementerad. I ett senare
stycke kommer vi introducera zonmodellen som en viktig säkerhetskontroll. Se sid 45
och ”Problem med zonmodeller” sid 68.
12 https://www.msb.se/RibData/Filer/pdf/27480.pdf
32/120
5.1.2 Logginsamling och loggbearbetning
Ett viktigt moment inom all hantering av IT- och informationssäkerhet är skapande,
bearbetning och insamling av spårdata, loggar.
Med hjälp av loggar går det att följa händelser i ett datorsystem, transaktioner i en
databas, vad som sker i en applikation eller vad en användare har för sig. Dessa loggar
kan sedan användas för en mängd olika saker, exempelvis:
> Statistik
> Debiteringsunderlag
> Felsökning och felavhjälpning
> Säkerhetsövervakning
Ett vanligt protokoll för överföring av logginformation är syslog-protokollet, som är en
internetstandard13. Detta möjliggör för en stor mängd applikationer, system och ut-
rustning att kunna skicka loggmeddelanden över nätverk. Tänk på att applikationer,
egenutvecklade system eller tredjeparts programvaror kan behöva konfiguration och
inställningar för att vara effektiva eller skapa användbar spårdata.
13 https://tools.ietf.org/html/rfc5424
33/120
Figur 7 Översiktsbild av loggserver uppsatt så att andra servrar skickar loggar och spårdata via nätver-ket
I bildexemplet har vi en centralt uppsatt loggserver. Den tar emot loggar från ett stort
antal olika tjänster och utrustningar. Dessa loggar kan vara:
> Loggar från applikationer
> Loggar från delsystem såsom databashanterare, mailtjänst, webbtjänst
> Loggar från operativsystem
> Loggar från nätverksutrustning såsom brandväggar, routers och switchar
> Loggar från lagringssystem
> Loggar från kringutrustning såsom nätverksskrivare
> Loggar från stödfunktioner såsom ventilationssystem, avbrottsfri kraft
Vikten av att ha god hantering av all logg- och spårdata ifrån all utrustning kan inte
nog påtalas. Genom att samla in, bearbeta och analysera loggar och spårdata kan
mönster detekteras, det går att lägga ihop händelser som involverar flera komponenter
och system.
34/120
Kapacitetsplanering och dimensionering av lagringsutrymme och nätverksöverfö-
ringskanaler kan vara andra viktiga parametrar som behöver utrönas i samband med
att man inför en logghanteringslösning. Detta är inte minst viktigt på grund av att man
inom många IT-avdelningar använder sig av dyra lösningar med lagringsnät, vilket
kan driva kostnaderna för logghantering till en orimlig nivå.
Rekommendation
Installera och ha lösningar för en effektiv logghantering.
Loggar kan användas för att bättre felsöka, bättre profilera användning och prestanda, men
är inte minst nödvändiga för att kunna hitta och utreda olika typer av säkerhetshändelser.
Inte sällan måste loggar från flera tjänster, utrustningar och system korreleras och analyse-
ras för att uppnå resultat. Därför är det viktigt med genomtänkt, och ofta centraliserad,
hantering av loggar.
5.1.3 Autentiseringstjänster
För att kunna bevisa att man har rätt att komma åt en tjänst eller logga in på en dator
måste man identifiera sig mot tjänsten eller datorn. Detta görs med hjälp av autentise-
ring. I vissa fall så är autentiseringsförfarandet distribuerat så att åtkomst sker via
nätverk eller att tjänsten eller datorn i sin tur via nätverket måst prata med en autenti-
seringstjänst.
Exempel på autentiseringstjänster inkluderar:
> Kerberos
> RADIUS14 (Remote Authentication Dial In User Service)
> TACACS15 (Terminal Access Controller Access-Control System)
5.1.4 Katalogtjänster
En katalogtjänst är ett slags uppslagsverk eller databas där information lagras centralt
och varifrån program i andra datorer i nätverket kan söka, hämta och bearbeta in-
formation. Exempel på vad som kan hittas i dessa katalogtjänster inkluderar använ-
darnamn, namn på skrivare, IP-adresser, krypteringsnycklar, e-postadresser och lö-
senord.
14 https://en.wikipedia.org/wiki/RADIUS 15 http://tools.ietf.org/html/rfc1492
35/120
Bland katalogtjänster kan nämnas:
> Active Directory, AD. Microsofts teknologi för kataloginformation
> Lightweight Directory Access Protocol, LDAP. En IETF-standard för åtkomst och
hantering av kataloginformation
Varianter av LDAP som heter LDAPS existerar. Dessa skapar en SSL/TLS-krypterad
tunnel över vilka sedan LDAP-förfrågningar och svar skickas.
Rekommendation
Använd alltid LDAPS, varianten som nyttjar en krypterad tunnel, för att skapa katalog-
tjänster eller för att slå mot en katalog.
5.1.5 Mjukvaruuppdateringar
En viktig säkerhetskontroll är att hela tiden hålla all programvara på en nivå där man
vet att den är fri från kända säkerhetshål och programfel som kan påverka säkerheten.
Ett sätt att hantera mjukvaruuppdateringar är att automatisera inhämtande av nya
programversioner samt distribution av dessa till relevant mottagarutrustning. Nästa
steg är att ha automatiserade funktioner för programvaruuppdateringar
En eller flera komponenter som är relevanta i detta sammanhang är att ha uppdate-
ringstjänster, vilket antingen är dedikerade servrar eller särskilda programvaror som
automatiserar programvaruuppdateringarna. För Microsoft Windows är detta i de
flesta fall MS WSUS. Det finns även tredjepartsprogramvaror för detta som kan han-
tera andra plattformar och även hantera uppdatering av produkter som inte omhän-
dertas av WSUS på Windowsplattformen.
Mjukvaruuppdateringar i allmänhet, och automatiserade sådana i synnerhet, är något
som inte är väl ansett i ICS/SCADA och processkontrollmiljöer. För en diskussion om
dessa risker och problem, se fördjupningsavsnittet ”Problem med patchhantering” på
sidan 66.
5.2 Övervakning, larm och uppföljning Övervakning av olika IT-resursers funktion, prestanda, kvalitet och tillgänglighet kan
vara en viktig del av säkerhetsarbetet. Övervakningen är ett sätt att så snabbt som
möjligt se viktiga händelser, avvikelser eller trender. Övervakning kan i sin tur ses
utifrån perspektiven:
36/120
> Nätverksövervakning
> Systemövervakning
> Applikationsövervakning
> Övervakning av säkerhetshändelser
Övervakningen har under normala driftsförhållanden till uppgift att upptäcka avvikel-
ser såsom högre än normalt nätverksutnyttjande, högre datorutnyttjande eller attack-
försök.
En viktig princip likväl som viktiga rutiner vad det gäller övervakning är att de insam-
lade larmen eller loggarna faktiskt analyseras och hanteras. Att enbart samla in över-
vakningsinformation som sedan inte används ger inte något mervärde ur säkerhets-
synpunkt.
Rekommendation
För att aktiv övervakning skall ge säkerhetsmässig effekt är det viktigt att insamlade larm,
loggar och annan spårdata analyseras och hanteras. Detta kan ske manuellt via operatörer,
automatiskt via larm- och logganalysverktyg eller genom kombinationer av dessa.
Ett sätt att hantera övervakningen av IT-system och IT-infrastruktur är att samla ihop
larm, loggar och annan spårdata till centraliserade servrar och övervakningstjänster.
37/120
Figur 8 Översiktsbild av larm- och övervakningserver uppsatt så att andra servrar skickar larm via nätverket
Bilden ovan visar en lösning där man skickar loggar och larm från olika enheter när en
onormal händelse uppstår. Dessa larm kan vara:
> Applikationslarm
> Systemlarm
> Larm från nätverksutrustning
> Larm från lagringssystem
> Larm från kringutrustning
> Larm från stödfunktioner, såsom ventilationssystem, avbrottsfri kraft
Det är viktigt att förstå att många typer av larm existerar i IT-sammanhang och att när man sammanställer dessa kan man få en bättre förståelse och bild av vad som verklig-en har hänt.
38/120
I dessa sammanhang, då vi pratar om IT-användning i samband med elbranschen och
dess olika företrädare, pratar vi ibland om ”tekniska larm” till skillnad från vanliga
larm. Ofta så finns det system, rutiner och roller för att hantera larm som är knutna till
energisystemets olika processer. Exempelvis så är larm något som hela tiden kommer
in till driftcentraler och hanteras i SCADA-system och de operatörer som jobbar med
dessa. Trots dessa larm så kan man i vissa sammanhang glömma att hantera de andra
typerna av larm – de tekniska larmen – som kommer från olika IT- och informations-
resurser som används.
Rekommendation
Konfigurera utrustning så att larm, i dessa sammanhang tekniska larm, skapas och skickas,
för att sedan tas emot och behandlas av driftorganisationens ansvariga. Larm är ett tecken
på att något är fel och att detta måste noteras och åtgärdas.
För en beskrivning och tillämpning av logg- och larmhantering, se avsnittet om SOC
”SOC, security operations centre” sid 64.
5.3 Nätverkssäkerhet I detta avsnitt gör vi en genomgång av olika komponenter och koncept som utgör de
skyddsmekanismer som finns på nätverksnivå.
5.3.1 Nättopologiska säkerhetsfunktioner
Bland de säkerhetskontroller och säkerhetsfunktioner som finns på nätverksnivå kan
nämnas:
> Brandväggar
> Åtkomstkontroll på nätverksnivå
> Nätverksbaserade intrångsdetekteringssystem
> Nätverksbaserade intrångspreventeringssystem
> Skyddslösningar för informationstapp, så kallad Data Loss Prevention, DLP.
> Nätverkskrypteringslösningar
> Logisk separation mellan subnät i samma utrustning, så kallade VLAN
> Logisk separation mellan nätverk, så kallad zonindelning
39/120
Brandväggar
Brandväggar har en väldigt central roll att spela som skyddsmekanism och säkerhets-
funktion på nätverks- och kommunikationsnivå. Brandväggen är en säkerhetskontroll
som har till uppgift att kontrollera trafikflödet på de anslutna nätverken. Utifrån upp-
satta regelverk kan trafik tillåtas passera baserat på ett antal attribut och värden asso-
cierade med nätverkstrafiken. Alternativt kan trafiken med hjälp av filtreringsmekan-
ismer blockeras helt eller till delar stoppas. Dessa händelser kan också generera logg
och larm i brandväggen.
I bilden nedan ser vi exempel när trafik, illustrerat med orange pil, från nätverk 2
stoppas i brandväggen, medan trafik från nät 1 till nät 2, illustrerad med grön högergå-
ende pil, tillåts passera.
Figur 9 principbild av hur en brandvägg fungerar
En vidareutvecklad principbild visar att brandväggen är placerad mellan två nät, där
den ena sidan är extern kommunikation till organisationen, den andra sidan är intern
kommunikation i organisationen samt att det finns ett tredje nät, ett nät som har nät-
tjänster. Brandväggen sitter ofta som avskiljare mellan externa delar och den egna
organisationen, vilket innebär att den får agera perimeterskydd för en elektronisk
perimeter.
När vi nedan pratar om utgående och inkommande trafik, så baseras dessa namn på
varifrån trafiken initieras. Inkommande trafik initieras från utsidan. Det finns sär-
skilda flaggor som betecknar detta i TCP-headerfälten, vilket möjliggör för brandväg-
gen att avgöra trafikriktningar.
40/120
Figur 10 brandväggsbild
Nästa principskiss visar en brandvägg som är placerad i ett internt nätverk, där den
agerar skyddsfunktion mellan ett processkontrollnätverk och koncernens övriga nät.
Även i detta fall kan det finnas en ut- och en insida på brandväggen, där insidan skall
skyddas från trafik som kommer från utsidan.
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
Att brandväggen är installerad så att man har interna resurser som måste skyddas från
externa angrepp är inte liktydigt med att trafikfiltrering inte skall ske på trafik från
41/120
insidesnätet. Det finns goda säkerhetsmässiga anledningar till att filtrera utgående
trafik. Normalt sett kanske bara vissa datorer får ha åtkomst externt. Eller att alla
datorer får ha extern åtkomst, men bara för vissa tjänster såsom HTTP för webb-
surfning. I dessa fall så finns det inte anledning att tillåta annan typ av utgående trafik
utan inskränkningar.
Det finns också scenarion där brandväggen hanterar två eller fler nätverk likvärdigt
och där skyddet i form av trafikkontroll och filtrering är lika starkt åt alla håll. Det
finns också scenarion där flera brandväggar seriekopplas, ofta för att olika nätverk
faller under olika organisationers driftsansvar och de olika parterna vill ha kontrollen
över en brandvägg, vilket gör att de får varsin brandvägg att bestämma regelverk i.
Rekommendationer
Brandväggar är en grundläggande säkerhetsfunktion för nätverkssäkerhet. Använd dessa
för att dela upp nätverk i mindre hanterbara enheter.
Var noggrann med att filtrera all typ av trafik i alla trafikriktningar. Släpp inte iväg ”utgå-
ende trafik” utan någon kontroll eller filtrering.
Utnyttja möjligheten att skapa DMZ-nät med hjälp av brandväggar, och placera tjänster där
som annars hade varit placerade långt in i det interna nätet, exempelvis tjänster för att
hämta och lämna filer, eposttjänster, med mera.
Logga inte bara stoppad trafik, utan se i vilken utsträckning det går att logga även tillåten
trafik. Vid en säkerhetsincident är det loggarna från den tillåtna trafiken som är mest in-
tressant att inspektera.
Det finns avancerade brandväggar som har möjlighet till att göra mycket mer avance-
rad filtrering och som det går att skriva mycket mer komplexa regler än att enbart
basera dessa på trafikriktningar och typer av tjänster. En vanlig utökning som finns i
avancerade brandväggar är granskning av överförd information, så kallad innehålls-
kontroll. Dessa brandväggar har blivit mer och mer standard idag då fler protokoll
måste hanteras med djupare analys för att verkligen kunna avgöra för vad som skickas
på nätet och om detta är tillåtet enligt säkerhetskraven.
För en mer utförlig diskussion om några av de vanliga problemen med brandväggar, se
kapitel ”Problem med brandväggar” sid 67.
Åtkomstkontroll på nätverksnivå
En viktig funktion är att kunna kontrollera och styra vilken utrustning som får ansluta
till organisationens nätverk. Med hjälp av åtkomstkontroll på nätverksnivå går det att
på detaljnivå styra detta. Vanligtvis så har företagsanpassad utrustning stöd för stan-
42/120
darden IEEE 802.1X, ibland även kallad EAPOL eller NAC – Network based Access
Control, som är det vanligaste sättet att styra detta. Dessa typer av standarder fungerar
både för de vanliga trådbundna och trådlösa nätverk som vi använder oss av idag på
företag.
Om man inte har åtkomstkontroll på nätverksnivå kan man drabbas av flera olika
typer av säkerhetsmässiga överraskningar och problem såsom att någon kan komma in
i ens trådlösa nätverk eller att någon obehörig kan ansluta en medhavd utrustning till
en exponerad nätverksport i receptionen eller i annat publikt utrymme. Det kan också
vara så enkelt att en behörig användare ansluter en dator till fel nätverk, där den inte
hör hemma. Ett sådant exempel vore att i ett elföretag ansluta en kontorsdator till ett
automationsnätverk, där den kan sprida skadlig kod eller påverka den industriella
processen med de programvaror som den har installerad.
Figur 12 Översiktsbild åtkomstkontroll på nätverksnivå
Föregående bild visar de olika steg som det innebär att utföra en åtkomstkontroll på
nätverksnivå. Den anslutande datorn måste vara utrustad med särskild programvara
som använder ett visst protokoll. Anslutningsutrustningen måste vara förberedd och
konfigurerad så att man använder exempelvis kontroll av elektroniska certifikat vid
anslutning av bärbara datorer på det trådlösa nätverket. Baserat på konfiguration av
accessutrustningen, hur jag blev godkänd och vilken profil jag har upplagd, kan jag få
43/120
en begränsad eller på olika sätt obegränsad åtkomst in i nätverket och till olika in-
formationsresurser.
Rekommendation Nätverksmässig åtkomstkontroll bör användas inom elbranschens olika företag för att und-vika att obehörig eller felaktig utrustning kan kopplas in, eller automatiskt ansluter, till nätverk.
För mer information om säkerhetsproblem och användbarhet med åtkomstkontroll på
nätverksnivå i samband med driftstörningar eller storstörningar, se ”Problem med
nätverksmässig åtkomstkontroll” sid 65.
Nätverksbaserade intrångsdetekteringssystem
Intrångsdetekteringssystem, ofta kallade IDS, är tekniska lösningar som är utformade
att uppfatta händelser, spår eller andra egenskaper som kan tolkas som tecken på att
ett angreppsförsök genomförs, att ett angrepp lyckats, eller att någon form av policy-
mässig överträdelse har skett. Om några sådana tecken eller mönster kan uppfattas så
skall IDS-lösningen agera, ofta genom att skicka larm eller skriva logg om att man
gjort en upptäckt.
IDS-lösningar finns i flera olika varianter, bland annat beroende på var någonstans de
är installerade och vilka typ av händelser den skall uppfånga och tolka. En typ av in-
trångsdetekteringssystem installeras och används i en dator och kallas därför ofta för
hostbaserad IDS. Denna typ av system används ofta för att upptäcka olika typer av
överträdelser eller avvikelser från normala användarmönster i en dator. En annan typ
av IDS-system gör kontroller och analys på nätverksnivå och kallas därför för NIDS,
nätverksbaserade intrångsdetekteringssystem.
Nedanstående bild visar principmässigt att det nätverksbaserade intrångsdetekte-
ringssystemet är installerat mellan brandväggen och bakomliggande klientdatorer
samt mellan klient- och serverdatorer. I praktiken kan detta vara ett och samma IDS-
system, även fast vi i denna bild gjort denna uppdelning för att tydliggöra den funkt-
ionella skillnaden att kontrollen görs mellan olika delar.
44/120
Figur 13 Översiktsbild över nätbaserade intrångsdetekteringssystem
NIDS-lösningen som sitter mellan brandväggen och all bakomliggande IT-
infrastruktur kan upptäcka såväl attacker från internet som från smittad utrustning
som ansluter till olika kommandoservrar.
Ett problem med nätverksbaserade IDS-system är den ökade mängden krypterad nät-
verkstrafik, eftersom det då blir svårt eller omöjligt för ett system som en IDS att
kunna inspektera överförd information efter tecken på säkerhetsproblem eller an-
grepp. Då mer och mer av datorkommunikation går via krypterad kommunikation, så
minskar användbarheten av IDS-system.
Rekommendation
Intrångsdetektering bör användas av alla företag i elbranschen för att upptäcka säkerhetsö-
verträdelser och IT-säkerhetsincidenter på nätverksnivå i organisationen. Ibland ingår
intrångsdetekteringsfunktionen i andra säkerhetsmekanismer, såsom i brandväggar, eller i
vanliga nätverksfunktioner såsom routers och switchar.
Nätverksbaserade intrångspreventeringssystem
Nätverksbaserade intrångspreventeringssystem (eng. intrusion prevention system),
IPS, är en teknologi som används för att såväl detektera som att automatiserat för-
hindra olika typer av säkerhetspåverkande händelser. Exempelvis så kan nätverksba-
45/120
serade IPS-system känna igen olika typer av attacker på nätverksnivå och där blockera
eller inte släppa fram nätverkstrafiken som innehåller själva angreppet eller attackför-
söket.
Figur 14 Översiktsbild över nätbaserade intrångspreventeringssystem
Intrångspreventeringssystem är användbara för att automatiskt kunna blockera hot
och attacker redan på nätverksnivå. Det kan vara ett mycket användbart skydd. Ett
IPS-system som av någon anledning gör ett felbeslut, exempelvis genom att en igen-
känningsregel är felprogrammerad, kan av misstag blockera riktig och viktig trafik. Det
kan få konsekvenser för de system eller applikationer som av misstag påverkas.
Rekommendation
Automatiserad intrångprevention har sina fördelar bl.a. genom att angrepp förhindras och
undviks. Det finns dock alltid risker med automatiserade motåtgärder. Det är extra känsligt
när sådana risker kan existera i IT-landskap där kritiska fysiska processer kontrolleras och
övervakas. Man bör noggrant överväga implementering av automatiserade motåtgärder i
vissa delar av IT-landskapet.
46/120
Logisk separation mellan subnät, VLAN
Virtuella LAN, så kallade VLAN, är ett sätt att i aktiv utrustning särskilja mellan olika
typer av nätverk. Med hjälp av VLAN-teknik går det att logiskt separera olika nätverk
från varandra så att man kan ha en struktur på olika nät och hur dessa nättopologiskt
distribueras ut via switchar etc. VLAN innebär en logisk uppdelning av nätet, även om
dessa nät fysiskt delar utrustning såsom kablage eller aktiv utrustning som nät-
verksswitchar. Separationen av olika nät hanteras i aktiv utrustning som kan dela upp
vilket nät som skall göras åtkomligt via vilken anslutningsport.
En viktig poäng att lyfta fram är att när man använder sig av VLAN så innebär det i sig
ingen total separering mellan de olika näten. Det är ett sätt att på en nivå separera
trafiken men trafik tillåts fortfarande att flöda mellan två nät. Det sker ingen filtrering
automatiskt enbart för att man har VLAN-teknik utan den funktionen måste användas
i kombination med tillexempel en router med accesslistor eller en brandvägg för att
begränsa trafikflödet mellan två nät.
Rekommendation
I de fall då VLAN-teknik skall användas för att skapa säkerhetsfunktioner, så måste VLAN
kombineras med andra trafikkontrollåtgärder såsom filtrering på nätverksnivå som sköts av
brandväggar, routers eller switchar.
5.3.2 Nätverkskrypteringslösningar
Ett sätt att skapa krypterade nätverk är att använda VPN, virtuella privata nätverk.
Poängen med att använda VPN-lösningar är att knyta ihop betrodda datorer med be-
trodda nätverk, eller helt enkelt att knyta ihop två betrodda nätverk, över ett annat
nätverk som inte är betrott, exempelvis Internet. Bilden visar hur två nät, skilda via
Internet, har brandväggar och särskild utrustning för att etablera VPN.
47/120
Figur 15 Översiktsbild av VPN-lösning
VPN är ett samlingsnamn på just den teknologi som ofta används för att skapa fjärråt-
komst till olika IT-resurser såsom interna servrar eller interna nättjänster.
Rekommendationer
Använd alltid krypterade VPN-tunnlar för fjärråtkomst till organisationens interna IT-
resurser.
Nedanstående bild visar hur en VPN-koppling sker. Mellan de två nätverken så etable-
ras en VPN-tunnel mellan de två VPN-gatewayservers som finns. Denna VPN-tunnel
medför krypterad trafik som skyddar mot avlyssning av överförd trafik, mot manipu-
lation av överförd trafik, samt attacker såsom återuppspelningsattacker.
48/120
Figur 16 Översiktsbild av VPN-lösning där kryptotunneln är etablerad
Förutom att använda dedikerad hårdvara, så kallade VPN-gateways, för att sköta eta-
blerandet av, och sessionerna med, de krypterade tunnlarna så används för vissa an-
vändningsfall istället särskild VPN-programvara. Så är ofta fallet när man har enstaka
fjärranvändare eller mobila användare som har bärbara datorer, plattor eller mobilte-
lefoner för att ha fjärråtkomst. Nedanstående bild visar ett steg längre, när klientdato-
rerna på det vänstra nätverket via VPN-tunneln kopplar upp sig till serverdatorer på
det högra nätverket.
49/120
Figur 17 Översiktsbild av VPN-lösning där kryptotunneln är etablerad mellan klient med VPN-programvara och en VPN-gateway
Det är viktigt att förstå att VPN är en term som har många innebörder. Att man har ett
virtuellt privat nätverk är inte liktydigt med att man har kryptering och en viss nivå av
skydd i alla sammanhang. Termen VPN används för tunnelbegrepp i den vanligt före-
kommande transmissionsteknologin MPLS16 som ett generiskt begrepp. Så en MPLS
VPN är normalt sett inte krypterad, utan mer ett sätt att separera trafik och att få
kommunikationsvägar uppsatta genom ett MPLS-nät. Likaså när man pratar om VPN i
de mer vanliga sammanhangen, att sätta upp en tunnel över ett TCP/IP-nät, så är det
viktigt att man är noggrann med hur man uttrycker sig och vad man menar. En VPN-
tunnel med tekniken IPSEC eller med tekniken SSL/TLS kan trots att det i normalfal-
let anses vara en krypterad tunnel ändå tillåta vissa fall där ingen kryptering är aktive-
rad eller meningsfullt etablerad. I samband med att kommunikationskanalen etable-
ras, förhandlas mellan två komponenter, så sker det också en förhandling om vilka
kategorier av krypteringsalternativ som skall användas. För flera överföringstekniker
såsom IPSEC och SSL/TLS så kan man, om det inte är explicit avstängt, förhandla
fram kryptovarianter där man har s.k. nullkrypto, vilket betyder att kommunikationen
kommer ske i klartext. Denna typ av ”val av kryptoinställningar” har av tradition fun-
nits med i protokollstandarder och i produkter för att klara vissa länders krav på ex-
porttillstånd, användning eller import av säkerhetssystem.
16 Multiprotocol Label Switching, en kommunikationsteknik för att skicka paketförmedlad digital trafik
50/120
Rekommendationer
Använd krypterade VPN-tunnlar för fjärråtkomst till organisationens interna IT-resurser.
För den tunnelteknologi som används, se till att använda starka kryptotekniker för att
skydda mot insyn och förändring av överförd information, skydd mot trafikanalys samt att
kunna kontrollera access och behörigheter i anslutningsutrustning.
En annan aspekt av kryptering är hur man sätter upp sin hantering av trafiken som går
i kryptotunnlarna. Är det uppsatt som ett radial- eller stjärnnät där alla enbart får nå
in till en punkt, själva VPN-gateway? Eller är det uppsatt så att man via en central
punkt kan nå till andra krypterade nät, d.v.s. att VPN-gateway är uppsatt som en slags
router som kan vidareförmedla trafik mellan olika anslutna nät. Detta är ett nättopolo-
giskt problem för vilket man måste besluta hur lösningen ska se ut.
Rekommendationer
Se till att fjärråtkomstlösningar använder krypteringsteknologier för insyns-, förändrings-
och manipulationsskydd av överförd information.
En annan fråga som är viktig att tänka på när man bygger nätverkskrypteringslösning-
ar är hur man hanterar själva kryptonycklarna. I princip så utgår resonemanget utifrån
två huvudalternativ:
1. Att nyttja X.509-certifikat med kryptonycklar
2. Att använda lösenord i form av en delad hemlighet mellan de kommunice-
rande enheterna
Av dessa två alternativ är alternativ ett det som säkerhetsmässigt är att föredra. Det
kräver dock att man har verktyg, processer och infrastruktur på plats för att skapa,
distribuera och att hantera kryptonycklar och certifikat.
Alternativ två innebär att man har en statisk delad hemlighet (eng. pre-shared key)
som används mellan de kommunicerande parterna, till exempel ett nät på ett lokal-
kontor som är anslutet via en VPN-gateway till en central VPN-gateway på huvudkon-
toret. Denna delade hemlighet, i praktiken ett lösenord eller en lösenordsfras, är något
som konfigureras in i programvara eller i kommunikationsutrustningen.
51/120
I en bra lösning så är denna delade hemlighet unik för varje anslutet VPN-nät. I en
mer osäker lösning så delas detta lösenord mellan många anslutna mobilanvändare
eller VPN-nät.
Rekommendationer
Använd inte en delad hemlighet (pre-shared key eller kryptonycklar/certifikat) för mer än
en uppkoppling. D.v.s. låt inte flera VPN-anslutningar dela på ett och samma lösenord. Om
en bärbar dator stjäls eller förkommer eller om det sker ett intrång i en kommunikationsut-
rustning så kan i värsta fall nätverksåtkomst ske ifrån andra uppkopplingar och nät.
Vidare på ämnet nätverkskrypteringslösningar så kan man tala om att använda VPN-
teknologi inte enbart för ansluta datorer eller nätverk över internet eller andra publika
nät mot det egna företagets nät. VPN kan också användas för att internt öka säkerhet-
en i vissa nät eller informationsöverföringar. Tekniker för VPN, såsom IPSEC, ingår
som standard i de flesta moderna operativsystem och i mycket av modern infrastruk-
turutrustning varför det inte är dyrt eller tekniskt komplicerat att nyttja det även för
interna säkerhetsbehov.
Rekommendationer
Nätverkskryptering i form av VPN-teknologi kan användas internt inom organisationen för
att skapa uppsäkrade kommunikationskanaler. Det kan ske såväl vid maskin-till-maskin-
kommunikation eller då man för vissa nätverk vill kommunicera över ett mellanliggande
osäkert nätverk.
För en vidare diskussion om tunnelteknik, säkerhet i distansarbetsplatser eller vid
fjärrsupport, se avsnittet om Fjärråtkomst sid 51 och avsnittet som handlar om Typfall
för fjärråtkomst sid 81.
5.3.3 Fjärråtkomst
Nätverkskrypteringslösningar används många gånger för fjärråtkomst till interna sy-
stem och IT-resurser av såväl egen personal som jobbar hemifrån eller som har jour-
tjänstgöring, men också av tredjeparts personal från olika leverantörer som jobbar
med felsökning och liknande.
En sak som måste tas i beaktande för alla varianter av fjärråtkomstlösningar är möj-
ligheter för obehöriga att bereda sig tillträde och åtkomst via dessa ingångar. Hur lätt
är det för någon att till exempel gissa lösenord? Eller kan det vara så att den utrustning
som man använt som skydd och säkerhetskontroll har inbyggda svagheter som kan
missbrukas för att ta sig igenom den?
52/120
Det är viktigt att fjärråtkomstlösningar är genomtänkta. Det finns flera olika sätt att
lösa fjärråtkomst på där man ställer olika för och nackdelar mot varandra. För inform-
ation om olika typfall av fjärråtkomstlösningar, se ”Typfall för fjärråtkomst” sid 81.
5.3.4 Nätverksmässig zonindelning
En säkerhetsfunktion på nätnivå är den så kallade zonmodellen. En zonmodell är ett
sätt att dela upp ett nätverk i mindre delar, så kallade zoner, vilka är avskilda från
varandra. En zon skall ha en klar och väldefinierad avgränsning. Säkerheten i en zon
hanteras såväl vid zongränsen, där man avgränsar mot andra zoner, och inom själva
zonen.
Exakt hur man delar upp nätet i zoner, hur stora dessa zoner är, vilken utrustning man
stoppar i en viss zon, hur man får utväxla information mellan datorer i olika zoner, är
något som bestäms i den specifika zonmodellen och hos den organisation som imple-
menterat zonkonceptet. Inte minst så bestäms det av ansvarig zonägare som är ansva-
rig för den zon som är aktuell.
En zon kan definieras som en gruppering av IT-resurser och informationstillgångar
som har likartade skyddsbehov från ett verksamhetsperspektiv.
En zon kan vara en ganska omfattande gruppering av informationstillgångar. Det är
viktigt att inte zoner blir alltför stora,exempelvis i form av att för många servrar eller
system är i samma zon utan någon inbördes inskränkning och begränsning i hur nät-
verkstrafik får utväxlas mellan dem. Därför kan det i vissa fall vara önskvärt att även
göra ytterligare inskränkningar och indelningar. En zon kan ha noll, en eller flera sub-
zoner. Sub-zoner är ett viktigt koncept, då det är ett sätt att skydda olika system från
varandra, även om de bedömts tillhöra en viss zon-nivå.
Ett annat sätt att se på zon-koncept och zonmodeller är att se det som zoninstanser. En
zoninstans kan vara kopplat till övriga zoner i ett och samma nät, men det kan också
vara en instans av en zonnivå som är frikopplad, eller kopplad till parallella nät där
man också har zoner.
Det finns flera olika typer av zonmodellskoncept utvecklade. Ett zonmodellskoncept är
att använda koncentrisk indelning som en lökmodell, där det finns flera lager med
ringar. Varje ring är en specifik zon. Som regel är lägre numrerade ringar mer skydds-
värda.
53/120
Figur 18 Översikt av en koncentrisk zonmodell
I denna koncentriska zonmodell innehåller varje zon en gruppering av system som har
samma eller liknande skyddsbehov.
Denna form av zonmodell samt numreringsschema används av flera stora svenska
elbolag. I denna modell så är zon 1 det som är mest närliggande den fysiska processen,
exempelvis elproduktion eller eldistribution.
I zonmodellen måste man ha en avgränsning till kritiska system, system som är viktiga
för processen. Inte sällan går den gränsen mellan zon 2 och zon 3, där system som är
kritiska för processen placeras i zon 2 och inåt mot zon 1.
54/120
Figur 19 Översikt av en koncentrisk zonmodell
I vissa implementationer av zonmodellen kan det vara så att man inte tillåter fullstän-
digt utbyte av information i bägge riktningarna mellan alla zonnivåer. Tillexempel kan
det mellan zon 1 och zon 2 vara uppsatt att det är en styrd envägskommunikation, från
zon 1 ut till zon 2. Detta kan vara för att förhindra åtkomst in till zon 1, där känsliga
system finns, trots att det måste tas ut vissa typer av information, exempelvis driftssta-
tus, larm och statistik från systemen i zon 1.
En annan zonmodell är Burtonmodellen, där olika zoner placeras på ett annat sätt,
som inte är helomslutande. Detta innebär bland annat att man på konceptnivå fören-
klar hur konsoler- och administrativ åtkomst in till de olika zonerna sker, likaså hur
loggning och spårbarhet skickas från de olika zonerna till en särskild övervakningszon.
55/120
Figur 20 Översikt av Burtons zonmodell17
Obetrodd zon inkluderar sådant som Internet och internetanslutna system. Kontroll-
zonen inkluderar sådant som konsolservrar eller administrations-PC som används för
att nå och styra utrustning i de andra zonerna. I andra sammanhang skulle detta
kunna kallas för ”Administrations-LAN”. Audit och övervakning är en zon där det står
loggservrar eller säkerhetssystem, exempelvis SIM/SEIM-tjänster, som fångar upp och
agerar på larm från olika IT-resurser.
Om man i bilden även lägger in information som beskriver hur information får delas
mellan olika zoner så får man en mer komplett förståelse av hur zonmodellen är tänkt
att fungera. Denna bild med informationsflöden visar att man enbart får skicka in-
formation till övervakningszonen.
17 http://www.slideshare.net/rnewton/webinar-burton-newcloudsecuritymodelrequirementsnov2009
56/120
Figur 21 Översikt av zonmodell där även regelverket för informationutbyte mellan zoner beskrivs
Denna zonmodell, med denna typ av uppdelning, har fördelar gentemot den koncent-
riska modellen, vad det gäller de zoner som används för administration eller övervak-
ning. Konceptuellt brukar dessa bli svåra att hantera i den koncentriska modellen.
Antingen så måste man ha administrationsdelar i varje zon, till exempel brandväggs-
konsoler. Eller så måste man bryta mot den koncentriska modellen och ha administ-
rationsutrustning som når och kontrollerar över zongränser, tillexempel att en Admi-
nistratörs-PC i zon 4 kan sköta en utrustning i zon 2.
En viktig fråga är kvaliteten på säkerhetskontroller i zongränserna mellan olika zoner.
Ett naturligt tekniskt skydd är att ha brandväggar som på nätverksnivå kontrollerar
kommunikation och informationsutbyte mellan zoner. Andra tekniska skydd som kan
finnas på zongränser är att man kräver autentisering (inloggning) och behörighetskon-
troll för den trafik som skall passera.
För mer diskussioner om teknisk lösning för separation, se kapitel om ”Brandväggar”
sid 39 och ”i vissa delar av IT-landskapet.
Logisk separation mellan subnät, VLAN” sid 45.
57/120
Rekommendation Vid införandet av en zonmodell, välj en zonmodell som är lätt att införa i den organisation som ni kontrollerar. Vid införande av en zonmodell, inför även zoninstanser och sub-zoner så att man bättre kan sköta uppdelning av system. Vid införande av en zonmodell, se till att införa rätt typ av säkerhetskontroller vid zongrän-ser.
En viktig del i införandet och förvaltandet av zonmodellen är att utse zonägare för
zoner eller sub-zoner. Det är dessa som är ansvariga och som därmed bestämmer vil-
ken kommunikation och nätverkstrafik som är tillåten till den aktuella zonen.
För en längre diskussion om problem och konceptuella utmaningar med zonmodellen,
se avsnittet ”Problem med zonmodeller” sid 68.
5.4 Identitetshantering och behörighetskontroll En viktig säkerhetskontroll och funktion i en säkerhetsarkitektur är att hantera behö-
righeter och kontrollera dessa. Alla moderna operativsystem och de flesta mer avance-
rade applikationer har bra stöd för behörighetskontroll.
5.4.1 Lösenord och lösenordsfraser
Den vanligaste mekanismen för att skydda ett IT-system mot obehörig åtkomst är att
använda en delad hemlighet, ett lösenord, som används för att kunna påvisa för datorn
att en användare är den som denne utger sig för att vara. Ett lösenord kan vara ett
flergångslösenord, att det går att använda vid återkommande tillfällen, eller ett en-
gångslösenord, att dess användning är förbrukad efter ett användningstillfälle.
Mer komplexa lösenord, större antal använda bokstäver och tecken, är svårare för
någon obehörig att gissa sig till eller använda ett datorprogram för att hitta lösenordet
med ordlistor, systematisk genomsökning eller forcering.
Lösenordsfraser är en variant av lösenord där man istället för ett ord, försöker skriva
långa meningar som man kommer ihåg. Det är ett sätt att skapa mer komplexa och
svårgissade lösenord.
5.4.2 System baserade på publika nyckellösningar, PKI
Ett i datorsammanhang vanlig system för behörighetskontroll är att använda publika
nyckellösningar, PKI.
58/120
Publika nyckellösningar kan antingen använda sig av certifikat som ligger lagrade på
fil eller på hårda certifikat som finns lagrade på aktiva kort.
Figur 22 Översikt av PKI-lösning
I bilden visas en användare som använder ett aktivt kort, ibland kallat för smart kort,
för att logga in i sin dator. Detta kort verifieras mot en katalogtjänst eller en verifie-
ringsserver.
5.4.3 Avancerade och federerade identitetstjänster
I avancerade fall så kan man använda sig av identitetstjänster som tillhandahålls av
andra parter, antingen inom den egna organisationen eller utanför den egna organisat-
ionen. Exempel på externa tjänster, protokoll och ramverk inkluderar:
> Oauth och Oauth2
> OpenID
> SAML
> BankID
De första av dessa är internationella standarder, som används ofta för att skapa olika
typer av gemensamma identiteter och möjligheter att logga in på olika tjänster på In-
ternet. BankID är en svensk lösning som bygger på att bankerna redan har upparbe-
tade kunddatabaser och kundrelationer. Genom att återförsälja dessa, där kunden
59/120
redan passerat en fysisk identitetskontroll, så kan bankerna erbjuda elektroniska iden-
titeter.
Det går också att bygga federerade identitetstjänster, där en tjänst tillhandahåller en
användaridentitet som kan användas inom flera organisationer. I federerade identi-
tetstjänster så är en eller flera parter s.k. Identity providers, IdP. Dessa identitetskällor
kan sedan vara en nätverkstjänst som alla andra, men som vid en kontroll går i god för
att en viss användares identitet är styrkt.
Rekommendation Använd inte komplicerade eller avancerade identitetslösningar, exempelvis med beroenden och kopplingar mot externa identitetskällor, på processnätet eller för SCADA/ICS-system och applikationer.
5.5 Skydd av information En central uppgift för alla moderna informationssystem och lösningar är att kunna
erbjuda skydd av information som är sparad, överförd eller under behandling.
5.5.1 Krypteringslösningar för överförd information
Att kunna skapa säkerhet för överförd information, ibland kallat ”data in transit”, in-
volverar någon typ av krypterad kommunikation på applikationsnivå eller i själva nät-
verkslagret.
Många lösningar som byggs idag nyttjar TLS-standarden för att skapa kryptering som
omsluter de kommunikationsprotokoll som används av applikationen.
Rekommendation När nya lösningar byggs eller köps in bör man idag som standard ställa krav på att all in-formation som överförs via nätverk skyddas med starka tekniska kryptolösningar.
5.5.2 Krypteringslösningar för sparad information
Krypteringslösningar för sparad/lagrad information, ibland kallat ”data at rest”, inne-
fattar att filer, databaser eller andra lagringsutrymmen krypteras. Kryptering av spa-
rad information är något som är lösningsspecifikt och dessutom kopplat till de behov
av skydd som är uppställt vid implementationen eller införskaffandet av applikationen
eller lösningen.
60/120
Det finns möjlighet att skapa egna lösningar för kryptering av sparad information i fall
där man, utan att påverka applikationer eller delsystem, kan aktivera krypterade filsy-
stem så att dessa sköts av operativsystem på ett transparent sätt.
5.6 Andra säkerhetskontroller Det finns andra uppsättningar med säkerhetskontroller, kontrollkataloger eller katego-
riseringar av kontroller. En sådan systematisering och kategorisering finns i den ame-
rikanska federala standarden NIST SP800-53 rev 418. Där finns det såväl metodbe-
skrivningar som beskrivningar och listningar av olika kontrollfamiljer.
6 Icke-tekniska lösningar
Detta kapitel beskriver övergripande de icke-tekniska skyddskomponenter och säker-hetskontroller som utgör delar av kontrollkatalogen. Detta inkluderar administrativa rutiner och åtgärder som kompletterar de tekniska kontrollerna.
Förra kapitlet fokuserade på olika typer av tekniska säkerhetsåtgärder. Alla IT-
säkerhetsproblem går inte att lösa med tekniska åtgärder, så därför behövs även andra
typer av lösningar och åtgärder. Ofta handlar det om att ha administrativa processer
och rutiner på plats som en del av ledningssystemet för informationssäkerhet och sä-
kerhetsarkitekturen. Denna lista är inte komplett, men vi tar upp några av de vanlig-
aste och viktiga kontrollerna här:
> Inventering av informationstillgångar
> Klassning av information
> Risk- och sårbarhetsanalys
> Säkerhetsanalys
> Säkerhetsgranskningar
18 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
61/120
6.1 Inventering av informationstillgångar Ett viktigt steg är att se vilka informationstillgångar – i form av system, applikationer,
nätverkskomponenter, databaser, som finns och används i organisationen. Invente-
ringssteget kan antingen ske automatiskt i samband med att nya system och informat-
ionstillgångar införs, eller som en särskild aktivitet. Inventeringen är också ett viktigt
steg för att upptäcka utfasade och glömda informationstillgångar.
Ofta sparas resultat av system- och informationsinventeringar i databaser, i vilka man
också för in sådant som informationsklassningsresultat av den inventerade informat-
ionstillgången.
6.2 Klassning av information Klassning, eller mer formellt klassificering, av information är en förutsättning för att
kunna göra ett bra säkerhetsarbete och kunna sätta in skydd på rätt ställen och till rätt
skyddsnivå. Klassningsarbetet utförs enligt en klassningsmodell. Klassning görs från
aspekterna sekretess (konfidentialitet), riktighet och tillgänglighet. Med detta menas:
> Sekretess: Att informationen skyddas från obehörig insyn
> Riktighet: Att informationen inte ändras på ett obehörigt sätt
> Tillgänglighet: Att informationen finns tillgänglig för rätt person vid rätt tillfälle
Många organisationer har idag inga system, metoder eller modeller för att klassa sin
information. I de fall då organisationen inte utför klassning, kan det vara för att en-
skilda i organisationen anser att andra skydd eller säkerhetskontroller, såsom att man
placerar system i en zonmodell, ersätter arbetet med att klassa system.
6.3 Risk- och sårbarhetsanalys En särskild aktivitet, som sätter norm och bestämmer mycket av utformningen i en
säkerhetsarkitektur är en risk- och sårbarhetsanalys.
Syftet med att ta fram risk- och sårbarhetsanalyserna är att identifiera potentiella och
befintliga hotbilder och att ta fram beslutsunderlag och därmed öka kompetens, med-
vetenheten och incitament hos chefer, beslutsfattare och verksamhetsrepresentanter
om hot, risker och sårbarheter inom det egna verksamhetsområdet. Därigenom skapas
möjligheter för att bättre sköta strategisk planering och verksamhetsplanering som är
utformad baserad på ett riskdrivet synsätt.
62/120
Risk- och sårbarhetsanalysen kan göras på ett förstadium, innan system, applikation
eller infrastruktur är på plats. Detta kan vara ingångsvärden när man utformar eller
upphandlar själva lösningen. Risk- och sårbarhetsanalysen kan också utföras på en
existerande lösning. Det kan innebära att man upptäcker att lösningens nuvarande
skyddsnivå och säkerhetskontroller inte är tillräckliga.
Mer information om risk- och sårbarhetsanalys finns bl.a. i Myndigheten för samhälls-
skydd och beredskaps vägledning för risk- och sårbarhetsanalys19.
6.4 Säkerhetsanalys Säkerhetsanalys enligt 5§ i säkerhetsskyddsförordningen (1996:633) är något som
elbolag behöver göra för att kontrollera vilka uppgifter i deras verksamhet som skall
skyddas med hänsyn till rikets säkerhet och vilka anläggningar som kräver ett säker-
hetsskydd med hänsyn till rikets säkerhet eller skyddet mot terrorism. Resultatet av
själva säkerhetsanalysen skall dokumenteras.
Mer information om säkerhetsanalys finns i Svenska kraftnäts vägledning säkerhets-
analys20.
6.5 Säkerhetsgranskningar Med hjälp av olika typer av säkerhetsgranskningar kan man undersöka den faktiska
nivån på säkerheten i system, applikationer, nätverk, driftcentraler eller liknande.
Målet med säkerhetsgranskningen är att antingen konstatera att allt är som det ska,
eller om det finns några säkerhetsmässiga problem eller sårbarheter. Det är snarare
regel än undantag att man vid säkerhetsgranskningar upptäcker olika sårbarheter.
Säkerhetsgranskningar kan utföras på många olika sätt, exempelvis
> Säkerhetstester, där man praktiskt genomför prov
> Analyser och genomgångar av systemdokumentation
> Källkodsgranskningar
> Baklängeskonstruktion (eng.)reverse engineering av program för att hitta säker-
hetsfel eller inbyggda svagheter.
19 https://www.msb.se/RibData/Filer/pdf/25893.pdf 20 http://www.svk.se/Global/01_Om_oss/Pdf/Sakerhetsskydd/Sakerhetsanalys.pdf
63/120
I den här vägledningen ska vi enbart titta på den första varianten, säkerhetstester.
6.5.1 Säkerhetstester
Säkerhetstester av informationsresurser är ofta utformade som praktiska tester, ibland
kallade penetrationstester, där målet, objektet, för undersökningen ansätts med olika
medel för att se ifall den klarar angrepp, felgrepp, felaktig inmatning, onormala an-
vändningsområden eller användningsfall, etc.
Ett väl utfört säkerhetstest skall vara kopplat till såväl klassningen av informationstill-
gången som till de risk- och sårbarhetsanalyser som utförts till de hot som är kända
mot just den testade utrustningen eller programvaran. Säkerhetstester hittar vanligtvis
problem och svagheter21.
Säkerhetstester kan utföras vid olika tillfällen. Ett sådant tillfälle är vid framtagande av
tjänster och funktioner som en del i utvecklingsprocessen. Tester kan också göras på
redan befintliga system, i utrustning och applikationer. Det kan bero på att det utförts
ändringar i IT-landskapet som i sig gör att det behövs en extrakontroll på att säker-
hetsnivån fortfarande är på en god nivå.
Säkerhetstester kan ses som ett kvitto på att alla andra förberedande steg i säkerhets-
arbetet, i detta fall också att säkerhetsarkitekturen, är väl utformade och rätt använda.
21 http://computersweden.idg.se/2.2683/1.538159/hur-man-misslyckas-med-en-sakerhetsgranskning
64/120
7 Implementationsfrågor
Detta kapitel beskriver många problem och frågor som uppstår i samband med att man skall införa säkerhetsarkitekturer.
7.1 SOC, security operations centre En så kallad SOC, (eng.)Security Operations Centre, ibland kallad kompetenscenter för
IT-säkerhet eller operativ säkerhetsövervakningscentral, är en funktion som ofta skap-
as internt inom ett företag eller en organisation för att samla funktionen på ett ställe.
SOC:en är den naturliga platsen för att ha hand om löpande säkerhetsarbetet såsom
att utvärdera larm och loggar, göra analyser av misstänkta säkerhetshändelser, ha
kontakt med externa parter såsom CERT-organisationer som CERT.SE eller ICS-CERT
eller att arbeta med penetrationstester och säkerhetsgranskningar.
7.2 Vanliga problem och utmatningar Det finns problem när en säkerhetsarkitektur skall införas, likväl som det finns pro-
blem när säkerhetsarkitekturen är installerad och det finns frågor rörande den löpande
verksamheten. I det här kapitlet har vi därför sammanställt ett antal problem och ut-
maningar. De problem och utmaningar som listas här kan vara:
> Vanliga till sin natur
> Ha att göra med vissa koncept (zonmodellen får ett stort fokus här)
> Kommer av att man använder sig av säkerhetskoncept i en särskild miljö med
särskilda förutsättningar (patchning, nätverksmässig åtkomstkontroll)
Detta avsnitt är med i vägledningen för att underlätta för läsaren när denne skall in-
föra olika säkerhetskontroller utan att samtidigt drabbas av några av de vanligaste
problemen.
7.2.1 Problem med skydd mot skadlig kod
I ICS/SCADA, processlösningar och automationssystem, så finns alltid det latenta
problemet med att det blir ett driftstopp om det kommer in okänd programvara eller
skadlig programkod i form av datavirus, maskar, trojaner eller annan liknande pro-
gramvara.
Därför behövs skydd mot skadlig kod.
65/120
I ICS/SCADA, process och automationssammanhang så finns det många problem med
att använda skydd mot skadlig kod, bland annat:
> Det finns leverantörsspecifik gammal hård och mjukvara som inte stöds av mo-
derna antivirusprogram
> Det finns gammal hård och mjukvara som inte stöds av moderna antiviruspro-
gram
> Det finns hårdvara och komponenter som inte stödjer att man laddar in nya till-
lämpningar, då de är byggda för att bara köra en viss programvara med en funkt-
ionalitet.
> Det finns problem med att få antivirusprogramvaror att ifrån processnät och ICS-
miljöer kunna hämta uppdaterade antivirussignaturer och nya versioner av sin
egen mjukvara.
> Leverantören av ICS/SCADA-lösningen tillåter inte att tredjepartsprogram install-
eras
Ett sätt att hantera några av dessa problem är att hantera viruskontroll på införda- och
utförda filer på annan plats, innan filer importeras eller exporteras ifrån ICS/SCADA-
miljön.
Ett annat sätt att hantera några av dessa problem är att hantera viruskontroll i
ICS/SCADA-miljön med så kallade vitlistor, listor på godkända program, snarare än
den metodik som antivirusprogram normalt sett använder sig av, så kallade svartlistor,
som är databaser med checksummor och kännetecken på virus och skadlig kod som
känns igen och därefter blockeras och/eller raderas. Vitlistningsteknik lämpar sig väl i
ICS/SCADA-sammanhang då denna miljö är statisk, isolerad och användarmönstren
är deterministiska på ett annat sätt än för vanlig kontors-IT. En annan fördel med att
använda vitlistningsteknik i ICS/SCADA-sammanhang är att denna teknik inte behö-
ver ansluta till Internet för att hämta hem nya databaser över svartlistade filer. Att inte
tillåta system inne i ICS/SCADA-miljön att ofta koppla upp sig mot Internet är en
ganska vanlig förutsättning för ICS/SCADA-system. I det fallet blir antivirusprogram-
met blockerat, och de svartlistor som hela tiden behöver underhållas för att känna igen
de nyaste hoten blir snabbt inaktuella.
7.2.2 Problem med nätverksmässig åtkomstkontroll
Nätverksmässig åtkomstkontroll bestämmer vilken utrustning som får kopplas in i
nätverket. Denna typ av åtkomstkontroll styrs ofta av centrala servrar som förstår
protokoll såsom RADIUS, TACACS, DIAMETER. Om denna teknik används i stor
66/120
skala, inklusive om den skulle användas ute i processnät, ICS/SCADA-ösningar, eller
liknande, så är det viktigt att det finns sätt eller vägar att i nödfall ändå kunna ansluta
utrustning.
Det klassiska problemet är att ingen vill hamna i en situation där man lyckats låsa sig
själv ute med hjälp av alltför väl fungerande säkerhetsfunktioner. I fallet med åt-
komstkontroll på nätnivå så är man rädd att projektpersonal, service- och underhålls-
personal eller motsvarande som är ute i en anläggning i samband med en storstörning
blir spärrad från att kunna arbeta med sin utrustning i stationen. Detta kan bero på
bland annat att kommunikationsstörningar har slagit ut kontakten mellan lokal ut-
rustning och centrala register för åtkomstkontroll till nätet. Fysiskt skyddade nät-
verksportar som sitter i ett larmat skåp kan vara ett sätt att ha en nödlösning för att
hantera att en inkoppling kan ske under extrema fall, även om man under normal drift
nyttjar de ordinarie nätanslutningsmöjligheterna.
7.2.3 Problem med patchhantering
En viktig säkerhetsåtgärd är att kontinuerligt hålla alla system och alla program på en
mjukvaruversion som är stabil och där alla kända säkerhetsproblem är åtgärdade. I
ICS, SCADA, automations- och processkontrollsammanhang så är det svårt att patcha,
lägga in programfixar eller uppdatera programvara i mycket av den utrustning och de
system som används. Dels för att det är utrustning som är produktionssatt. Dels för att
programvaran i den utrustning och de system som säljs av ICS- och processkontrolle-
verantörer ofta är noga uttestad att fungera, och att de programkomponenter som
finns är utformade och noggrant testade att fungera ihop. Om delar av programvaran
byts ut kan det innebära att vissa funktioner, gränssnitt, filformat eller annat ändras.
En annan typ av problem är underhåll och löpande förvaltning av olika utrustningars
lågnivåprogramvara, så kallad firmware. Som all programvara så kan firmware inne-
hålla programfel, buggar. Likaså kan vissa av dessa programfel vara säkerhetsbuggar
eller på annat sätt ha påverkan på utrustningens robusthet. En trend för vanlig utrust-
ning, såsom datorer som används som server,klientutrustning eller kommunikations-
utrustning i kontorsnätverk, är att dessa aktivt underhålls även med uppdatering av
firmwareprogramvaran.
7.2.4 Problem med PKI och certifikathantering
Ett särskilt problemområde är hantering av PKI-lösningar och därtill hörande certifi-
kathantering. Det finns mängder med frågor och problem som måste hanteras inom
detta område, inte minst när vi pratar om inbyggda system, specialhårdvara såsom
PLC, RTU:er, enkortsdatorer, videokameror, m.m. Bland dessa frågor finns:
67/120
> Hur ska certifikat utfärdas vid utrullning av utrustning?
> Hur ska rootcertifikat utfärdas?
> Hur ska rootcertifikat distribueras om man använder sig av egen CA och egen
PKI?
> Vad är lämpliga giltighetstider på utställda certifikat?
> Skall man ha egna CA och PKI-lösningar för ICS/SCADA-miljöer eller dela dessa
med övriga IT-tjänster och IT-miljöer?
Utan att gå in och svara på var och en av dessa frågor så är det nog enklast att konsta-
tera att detta är specifikt för de krav och behov som finns för varje organisation. Gene-
rellt kan man säga att de krav och behov som finns för ICS/SCADA-system är speciella,
vilket gör att de utställar-policies (CP & CPS) som har tagits fram för att ställa ut certi-
fikat för användning i kontorsmiljön kan behöva justeras. Inte minst på grund av att
man till varje pris måste undvika att hamna i situationer där utgångna certifikat spär-
rar tjänster eller förhindrar IT-funktioner i ICS/SCADA-miljön att fungera korrekt.
7.2.5 Problem med brandväggar
Ett problem med brandväggar kan vara att de inte är korrekt uppsatta, utan att de är
felkonfigurerade och därför släpper igenom alltför mycket nätverkstrafik.
Ett vanligt problem är att de brandväggar eller den nätutrustning med filtrering som
man förfogar över inte har stöd för den nätverkstrafik som finns på nätverket. Ett så-
dant klassiskt problem är att brandväggen inte alls, eller inte fullt ut, stödjer det bä-
rande kommunikationsprotokollet IPv6 utan bara stödjer IPv4.
Ett annat vanligt problem med brandväggar är att de inte är konfigurerade på ett sätt
så att de både skyddar och samtidigt genererar spårdata över genomsläppt eller spär-
rad trafik. Det är vanligt att inte viktiga händelser lämnar spårdata efter sig, till exem-
pel att olika försök till angrepp inte blir synliga i loggar.
Ett annat problem med brandväggar är att inte alla nätverksprotokoll är lätta att han-
tera i brandväggar. Vissa protokoll är mer komplexa, vilket gör att brandväggen inte
kan göra analys av trafiken och fatta rätt beslut. Det är också ett problem att vissa
protokoll är krypterade så att brandväggen inte kan få insyn i trafiken och fatta beslut
som bygger på de regler som är uppsatta i brandväggen.
Andra problem med brandväggar är att själva brandväggen inte sköts av, eller är åt-
komlig för, den egna organisationen. Hos många organisationer förekommer utlagd
68/120
drift. Då kan nätverk och säkerhetskontroller såsom brandväggar skötas av någon
annan organisation.
7.2.6 Problem med zonmodeller
Införande av nätverksmässiga zoner har många fördelar, jämfört med att ha platta
datakommunikationsnätverk utan gränser eller barriärer där säkerhetskontroller och
skyddsmekanismer används.
Det finns ett antal problem med införande eller användande av zonmodellen. Vissa
problem är tekniska och vissa är av mer konceptuell karaktär. Andra har att göra med
vilken typ av zonmodell man valt, andra med hur man väljer att implementera en mo-
dell. Sist men inte minst så finns det flera problem som har att göra med förståelse
eller avsaknad av drifterfarenheter med zonmodeller.
Följande lista är en sammanställning av några vanliga problem som berör zonmodeller
som säkerhetskoncept. Flera av punkterna beskrivs mer ingående efter själva listan:
1 Att bestämma vad är det som anses vara mest skyddsvärt och det som således sätts
”längst in” i zonmodellen
2 Att konvertera och gå från en befintlig nätinfrastruktur och nättopologi till en
nätinfrastruktur som är baserad på zonmodellen
3 Att zonmodellen inte införs helt och hållet inom hela organisationen eller inom
hela företaget
4 Att zonmodellen inte gäller för partnerföretag, företag som man utväxlar inform-
ation eller e-tjänster med
5 Att zonmodellen inte gäller för delar av IT-miljön som inte är under egen kontroll,
exempelvis molntjänster, XaaS-lösningar, helt eller delvis utkontrakterad drift,
etc.
6 Att man bara skyddar vissa nät, men inte andra nät såsom exempelvis administ-
rations-LAN, LAN för säkerhetskopiering, mm.
7 Att man bara skyddar Ethernetbaserade IP-nätverk, men inte andra typer av nät,
såsom exempelvis lagringsnät.
8 Att virtualisering av olika infrastrukturkomponenter kan kortsluta zonmodellen.
9 Att de förväntade effektiviserings- och rationaliseringsvinsterna med virtuali-
sering av olika serverkomponenter inte uppnås på grund av att nätverstrafik inom
VM-Warefarmen,klusterlösningen eller motsvarande inte uppnås, på grund av att
69/120
all kommunikation måste skickas till fysisk kommunikationsutrustning som slus-
sar trafik mellan olika nät eller olika zoner.
10 Att det är oklart var vissa IT-resurser såsom vissa tjänster, vissa system eller kom-
ponenter skall placeras mest naturligt eller placeras bäst.
11 Att vissa zoner blir för stora och skulle behöva delas upp i mindre delar.
12 Att uppdelningen i zoner upplevs som, framhävs som eller helt ersätter andra
säkerhetskoncept såsom informations och systemklassning.
13 Att det finns kommunikationsbehov som spänner över många zongränser, och att
man väljer att korsa zongränser för att koppla samman kommunicerande system.
Dessa typer av kortslutningar, särskilt när det gäller krypterad trafik eller tunnel-
trafik, kan helt sätta zonmodellens principiella och tekniska skydd ur spel.
14 Att en zon kortsluts genom att en eller flera zongränser överskrids med hjälp av
andra nätkopplingar, exempelvis trådlösa nät i form av WiFi, GSM, 3G, 4G,
WiMax, ZigBee, Blåtand eller annat. Även trådbundna nätverk, i form av seriell
kommunikation eller icke-IP-baserad kommunikation (det finns ICS/SCADA-
produkter som använder sig av OSI som bärartjänst) kan innebära riskabla eller
ogenomtänkta zonövergångar.
15 Att en zonmodell upplevs som om allt måste kopplas samman och infoga sig i
modellen och det i zoner uppdelade nätverket.
16 Oklara ansvarsförhållanden eller inte tilldelat ansvar och roller vad gäller ägarskap
av olika zoner.
17 Att inte tillräcklig kraft eller fokus läggs på de säkerhetskontroller som måste im-
plementeras i zongränser. Detta gäller särskilt de gränser som vetter mot process-
kontrolldelarna.
Alla ovanstående punkter är var och en tänkvärda och kräver bearbetning och efter-
tanke om man skall införa en zonmodell.
Punkt fyra och fem är alltmer växande problem då fler och fler företag köper IT i form
av tjänster och externa tjänsteleveranser. I vissa fall går det att påverka de externa
tjänsteleverantörerna att anamma ens egna interna säkerhetskrav och säkerhetsarki-
tektur i form av zonmodellen men oftast går det inte.
Punkt åtta är särskilt problematisk. Sådan kortslutning kan uppstå efter man har in-
fört en lyckad zonmodelluppdelning, och att man därefter i utbyggnad av virtuali-
seringslösningar ersätter fysisk nätutrustning med virtuella switchar, routers, brand-
70/120
väggar eller liknande. Detta medför inte sällan att virtualiseringslösningen faktiskt
kortsluter en redan införd zonuppdelning.
Punkt nio fokuserar på prestanda som kan bli lidande om en lösning är väl genom-
tänkt. Det gäller att på förhand veta hur olika virtuella och fysiska lösningar skall
kopplas ihop, hur back-bone-trafik är dimensionerad och tänkt att gå. Om en lösning
som först är tänkt att gå helt inom servrars virtuella nät ändå måste skickas ut till en
fysisk extern brandvägg för att trafik skall skickas mellan olika subnät, subzoner eller
zoner, så kan detta få omfattande påverkan på prestanda.
Punkt tio. Tidgivning i separerade segment är en viktig fråga. Den måste hanteras på
ett eller annat sätt. Antingen får tid synkroniseras mellan zonerna, med hjälp av olika
tidsdistributionsprotokoll. Ett annat alternativ är att ha tidsservrar i varje zon, sub-zon
eller zoninstans som själva har anslutning till en tidskälla, exempelvis GPS-mottagare.
Punkt tolv. Det är mycket viktigt att man skapar en säkerhetskultur och säkerhet i de
olika lösningarna där zonkonceptet enbart är en säkerhetskontroll och att den inte
ersätter andra, såsom informations- eller systemklassificering. Det är lätt att förledas
att tro att det säkerhetsmässigt räcker att gömma system och applikationer bakom
olika barriärer, d.v.s. zoner och zongränser. Det är en felaktig slutsats. Man måste
fortfarande göra informationsklassning och systemklassning för att få ut nivån på olika
skydd (exempelvis vilka loggar som skall skapas eller hur länge dessa skall sparas),
något som inte kommer fram med zonplacering.
Punkt tretton, där man i överföringen hoppar över zoner, obehindrat passerar en eller
flera zoner, i informationsöverföringar innebär såväl ett brott mot konceptet och kan i
praktiken sätta säkerhetskontroller och övervakningsfunktioner ur funktion.
Punkt 14, att det kan finnas kortslutningar genom att nätet inom en zon kopplas sam-
man med andra nät via en annat kommunikations- eller transmissionsteknik, är en
viktig poäng. Ett zonindelat nät är bara så skyddat och övervakat som de anslutningar
och zonövergångar som är godkända.
Punkt 15 är viktig, då man inte får glömma eller utesluta alternativet att det kan finnas
isolerade, fristående, autonoma eller parallella kommunikationsinfrastrukturer som
inte behöver, eller kanske tillochmed inte bör, kopplas ihop med övriga nät som är
ihopkopplade i det zonmodellsuppsatta nätverket.
Punkt 16 är självklar, men kan ändå uppstå i praktiken i större organisationer. Att ha
tekniska säkerhetskontroller och skydd hjälper inte om inte roller besätts och att de
som tilldelats roller och ansvar aktivt arbetar med frågorna.
71/120
Punkt 17 Det är viktigt att skydd implementeras i zonövergångar. Dessa skydd kan vara
exempelvis brandväggar, men de kan även vara andra typer av skydd, såsom proto-
kollöversättningsprogram som översätter mellan ett kommunikationsprotokoll till ett
annat. Det kan också vara olika typer av autentiserings- eller behörighetskontroll-
funktioner som kontrollerar identiteten på användare eller kommunicerande program
samt ser ifall dessa har rättigheter för att utföra de operationer som sker över zongrän-
sen.
7.2.7 Problem med testning
Testning är en viktig del i att kunna ha en bra säkerhetsarkitektur. Att bara ha pro-
duktionssatt utrustning och inte ha testutrustning eller testmiljöer där olika typer av
testning kan utföras leder till mängder av problem, såsom att programpatchar inte kan
testas innan de läggs på i produktionsmiljön. Bra testning, bland annat regressionstes-
ter av infrastrukturkomponenter eller system gör det lättare att utföra förändringar i
produktionssatt miljö. Viktigt är också att kunna ha automatiserad testning så att test-
fall är repeterbara. Likaså att det är lätt att bygga på befintliga testfall. Det är viktigt att
de automatiserade testerna innefattar både positiva och negativa tester och testfall.
Säkerhetstester, som introducerades i kapitel ”Säkerhetstester” sid 63 har sina egna
problem. Ett exempel är att det är svårt att veta om testningen är tillräckligt omfat-
tande eller djupgående. Ett dåligt säkerhetstest kan genomföras utan att uppnå resul-
tat. Men det kan ett väl genomfört säkerhetstest också resultera i.
En annan typ av tester är prestandatester, som ibland också kallas lasttester, där man
kontrollerar hur mycket ett nätverk, en server eller en applikation klarar i antal upp-
kopplingar, antal överförda paket, med mera. Ett problem med prestandatester är att
de inte alltid utförs på system och infrastruktur som motsvarar den målmiljö som
slutligen används. Ett annat problem är att de tester som utförs kanske inte alltid är
realistiska och motsvarar hur lösningen kommer att användas.
7.2.8 Problem med loggning, logghantering och spårdata
Loggning är en viktig funktion för att ha underlag för att kunna utföra felsökning, eller
för att kunna eftersöka olika säkerhetshändelser.
Vanligaste problemen med loggar och loggning är:
> Att det inte är rätt, eller tillräckligt detaljrik, information som loggas.
> Att loggar inte är fullständiga.
> Att loggar inte sparas tillräckligt länge.
72/120
> Att loggar inte går att läsa tillbaka från säkerhetskopior.
> Att loggar från olika system inte går att pussla ihop för att det inte finns någon röd
tråd som gör att de stämmer.
> Att loggar från olika system inte går att jämföra för att det är fel med tider och
tidssynkronisering mellan de olika systemen.
Att loggar inte går att läsa tillbaka från säkerhetskopior kan ha flera olika orsaker,
exempelvis att loggarna sparas utspritt på så många säkerhetskopior att det tar orim-
ligt lång tid att läsa tillbaka. Ett annat relaterat problem kan vara att säkerhetskopi-
orna inte sparas så pass länge som behövs för att komma åt vissa gamla loggar.
Ett sätt att hantera loggar i Windows är att samla dom på en centraliserad loggserver.
Alla versioner av Windows har sedan Windows XP SP2 möjlighet att göra s.k.
”subscribe” på logghändelser, så att loggar kan centraliseras. Detta är ett enkelt sätt att
skapa en centraliserad loggtjänst i en windowsmiljö exempelvis i ett process-nät.
Ett problem med att skapa loggar är stora loggvolymer. Många gånger måste man vara
selektiv med nivån på loggning. Har man för mycket loggning aktiverat i ett system så
kan det bli så att loggarna fyller diskar eller att en servers prestanda påverkas negativt.
Vissa komponenter och lösningar bör ur ett säkerhetshänseende ha en annan nivå av
policy när det gäller loggning. Säkerhetskomponenter såsom brandväggar bör logga så
mycket som möjligt eller all trafik och alla händelser, oavsett om det är positiva eller
negativa händelser.
7.2.9 Problem med hantering av komponenter utan egen säkerhet
Ett särskilt problem är hanteringen av olika komponenter som inte har egen inbyggd
säkerhet. Det kan vara exempelvis skrivare, gamla datorer med ålderstigna operativsy-
stem, inbyggda system eller speciallösningar.
Hur ska man hantera komponenter som inte har egen säkerhet? Det finns en mängd
olika åtgärder som kan utföras, antingen enskilt eller i kombination med andra säker-
hetskontroller:
> Isolera fysiskt.
> Isolera logiskt.
> Låsa in fysiskt.
> Tunnla trafik med hjälp av mjukvara.
> Tunnla trafik med hjälp av hårdvara.
73/120
Dessa olika åtgärder kan genomföras genom att exempelvis ha tjänster på egna separe-
rade datorer, ha datorer på egna nät, använda virtuella maskiner som ett sätt att isole-
rar enskilda gästdatorer som kör osäkra program eller operativsystem.
74/120
8 Översikt över IT-funktioner som finns i ett elföretag
Detta kapitel beskriver på ett översiktligt sätt olika IT-funktioner som kan finnas i ett elbolag. Vissa av dessa IT-funktioner och informationsresurser beskrivs mer ingående i kapitlet, då de kräver särskild uppmärksamhet ur ett säkerhetsperspektiv.
Ett vanligt företag inom den svenska elbranschen som producerar eller distribuerar el
har många olika delar i sin IT-miljö. Nedanstående lista är ett sätt att katalogisera och
systematisera de vanligaste av dessa IT-resurser. Dessa IT-resurser visar på olika sätt
hur IT-används i elbolag. Dessa behöver därmed också skydd och löpande underhåll
för att behålla rätt nivå av skydd över tid.
Genom denna listning så kan man både försöka finna mönster och typfall, men också
fundera på andra återkommande problem eller specialfall som finns i IT-landskapet.
Listan är en bra startpunkt för att strukturerat börja arbeta med att på att koppla IT-
resurser till säkerhetsarkitekturens olika säkerhetskontroller. Genom en inventering
av det egna IT-landskapet och denna lista kan ett systematiskt arbete utföras för att
bygga ett IT-landskap som är baserat på en säkerhetsarkitektur.
Listan är uppdelad i sex delar, där såväl IT användning inom kontorsautomation och
processkontroll samt övriga system såsom passagesystem och andra funktioner tas
upp:
1 Kontorsnät och kontorsautomation
• Klientapplikationer för ordbehandling, beräkningar och presentation
• Klientapplikationer för att surfa på interna och externa webbtjänster
• Klientapplikationer för att skicka och ta emot elektronisk post
• Klientapplikationer för att kunna fakturera
• Klientapplikationer för att kunna hantera kundtjänstärenden
• Klientapplikationer för att hantera dokument och åtkomst till dokumentarkiv
• Klientapplikationer för framställande, hantering och arkivering av ritningar
• Klientapplikationer för intern administration
75/120
• Serverdelar, såsom filservrar, databasservrar, arkiv, mm
• Stödsystem för processautomation, nät- och anläggningshantering som ligger
utanför processtyrningen, till exempel logistik, arbetsorder, grafiska informat-
ionssystem, beräkningar enligt nätnyttomodellen, mm
• Supporttjänster såsom katalogtjänster, namnuppslagning, säkerhetskopie-
ring, tidssynkronisering, loggning, m.m.
• Kommunikationsinfrastruktur
2 Processautomation
• Klientdatorer för styrning och övervakning av processen
• Enkla specialdatorer för styrning och övervakning av processen, HMI-
utrustning
• Specialdatorer för programutveckling och parametersättning av styrdatorer
(Engineering workstations, mm)
• Specialdatorer och specialkomponenter för processkontroll, exempelvis PLC,
RTU, protokollkonverteringsgateways, serieportsomvandlare, m.m.
• Serverdatorer för styrning och övervakning av processen, t.ex. SCADA, DCS.
• Supporttjänster såsom katalogtjänster, säkerhetskopiering, tidssynkronise-
ring, loggning.
• Kommunikationsinfrastruktur
3 Extranet och partnerkopplingar
• Projektplatser och portaler
• Integrationsnav, dataimport och dataexport till andra företag
• Filöverföringsfunktioner
• Supporttjänster såsom katalogtjänster, namnuppslagning, säkerhetskopie-
ring, tidssynkronisering, loggning, m.m.
• Kommunikationsinfrastruktur
4 Fjärråtkomst
• Fjärråtkomst för egna anställda, till exempel för hemarbete eller vid jour
76/120
• Fjärråtkomst för egna anställda, till exempel för fältpersonal med bärbara da-
torer eller handdatorer, som används för åtkomst till arbetsorder, nätkartor,
logistiksystem, m.m.
• Enstaka temporär fjärråtkomst för externa personer, exempelvis entreprenö-
rer, reparatörer, leverantörer. Detta sker t.ex. vid projekterad serviceperiod.
• Återkommande temporär fjärråtkomst för externa personer, exempelvis ent-
reprenörer, reparatörer, leverantörer. Detta sker t.ex. för att kunna ha ser-
viceavtal
• Permanent fjärråtkomst för externa personer, exempelvis entreprenörer, re-
paratörer, leverantörer, support.
• Sammankoppling av nät mellan företag, t.ex. för att kunna erbjuda vissa tred-
jeepartstjänster såsom optimering av processen, förebyggande underhåll, etc.
Detta inkluderar olika M2M (maskin-till-maskinkopplingar) lösningar.
• Kommunikationsinfrastruktur
5 Internettjänster
• Mailserver
• Webbservers med allmän information
• Webbservrar med kundinformation, typ mina sidor
• Filöverföringsfunktioner
• Supporttjänster såsom katalogtjänster, namnuppslagning, säkerhetskopie-
ring, tidssynkronisering, loggning, mm.
• Kommunikationsinfrastruktur
6 Övrigt
• Passagesystem, undercentraler, servrar, kort- och fotokiosk
• Övervakningssystem med säkerhetskamera
• Kamerasystem för annan okulärkontroll, exempelvis mot dammarnas ut-
skovsluckor
• Porttelefoni: telefoner, undercentraler, servrar
• Dammvibrationsmätningar
• Miljöövervakningssystem
77/120
• Brandlarm, Inbrottslarm, larmsändare
• Fastighetsautomation: VVS, m.m.
Förutom dessa typfall av ovanstående IT-lösningar så förekommer det ett stort antal
andra användningsfall som:
> Användning av XaaS, X as a Service, där man köper tjänster via nätet av en tjäns-
televerantör. X kan vara sådan som E-post, Säkerhet, Infrastruktur, Övervakning,
Säkerhetskopiering, med mera
> Andra typer av molntjänster, såsom kontorsautomation i form av office-program.
Dessa användningsfall och typer av tjänster eller tjänsteleveranser, är speciella i flera
avseenden. Ett par gemensamma saker för flera av dessa är standardleveranser, som
någonstans i kedjan delas med andra kunder, samt att det är liten eller ingen transpa-
rens i tjänsternas tekniska uppbyggnad, operativa drift och förvaltning, och ingen
direkt transparens om säkerheten utöver vissa säkerhetsutfästelser.
Ett område som behöver viss specialhantering i typfallslistan är kategori 2a i listan,
”Klientdatorer för styrning och övervakning av processen”. Detta särskilt i det fall då
klientdatorerna är placerade i en driftcentral (DC), bevakningscentral eller liknande.
Det finns flera säkerhetsaspekter med denna kategori som kräver extra omtanke och
särskilda lösningar:
> Hantering av uppdateringar av systemprogramvara, typ windowsuppdateringar.
Det finns många tillfällen då uppdateringar, eller automatiska uppdateringsproce-
durer, inte är lämpliga att utföra i en driftcentral, exempelvis under en storstör-
ning eller när vissa typer av underhållsarbeten görs.
> Behörighetskontroll och hantering av inloggade användare. Inte sällan är driftcen-
traler uppbyggda så att en användare är inloggad konstant på de skärmar som an-
vänds för att visa upp processbilder, skisser, kartor eller liknande.
Ett område som är svårplacerat i ovanstående kommunikation som sker mellan elbo-
lagen mot diverse anläggningsnät eller tom kundplacerad utrustning. Detta inkluderar
sådant som elkvalitetsmätning, fjärravläsning av mätare, m.m. Detta område kompli-
ceras ytterligare när ny teknologi såsom smarta elnät, (eng.)smart grid, börjar komma
in alltmer i elföretagens elnät.
78/120
Som det går att se av ovanstående typfall och områden så är område 4, fjärråtkomst en
viktig del med många variationer och typfall för många organisationer inom elbran-
schen.
Kategori 6, övrigt, är ofta särskilt problematiskt. Dels blir den förbisedd, bortglömd,
eller är bara illa sedd eftersom den inte är en klassisk IT-lösning som ryms inom ordi-
narie hantering eller hanteras med ordinarie processer. Inte sällan är det specialhård-
vara eller vanlig hårdvara som ändå skall ha installerats med programvara som inte är
eller kan vara utförd i enlighet med organisationens standardförfarande. Det är viktigt
att dessa typer av system omfattas av ordinarie säkerhetskrav, underhålls och förvaltas
på samma sätt, eller så snarlikt sätt som möjligt. Risken är annars stor att dessa typer
av servrar saknar säkerhetuppdateringar, är konfigurationsändringar till exempelvis
GPO och windows gruppolicy inte uppdateras.
79/120
9 Referensarkitekturer
Detta kapitel beskriver olika delar av mer kompletta referensarkitekturer. Vi inleder med en allmän del, för att sedan beskriva referensarkitekturer med hjälp av Open Security Architectures standardfall för att avsluta med referenser och kopplingar mot standarden IEC 62443.
Dessa referensarkitekturer är tänkta att bygga med de olika tekniska komponenter och
beståndsdelar som redovisats tidigare i dokumentet. I denna del så sätts flera av dessa
komponenter ihop, så att byggklossarna visar en större helhet.
Denna del innehåller flera olika typfall som är vanliga i elbranschen.
9.1 Allmän översikt De typfall som beskrivs i denna del av vägledningen inkluderar:
1 Nätverksuppdelning i form av nätsegment, zoner eller liknande
2 Fjärråtkomstlösningar
3 Användningen av DMZ
4 Kopplingar mellan kontors-, koncern- och processnät på ett skyddat sätt.
5 Lösningar där man använder sig av utökade funktioner för loggning och övervak-
ning.
9.1.1 Referensmodell med uppdelat nät
Ett elföretags interna nätverk och IT-miljö innehåller många olika typer av verksam-
het, exempelvis såväl vanlig kontorsautomation som processautomation i processnät.
Man kan vilja särskilja dessa två kategorier av nätverk av olika skäl. Ett klart sådant
skäl är att processnäten och dess utrustning såsom SCADA-servrar, PLC, enkortsdato-
rer och inbyggda system ofta är bräckligare och mer störningskänsliga än vanliga kon-
torsdatorer. Denna bräcklighet i kombination med att dessa system styr den faktiska,
fysiska, processen för elproduktion, eldistribution eller liknande, medför att dessa
nätverk behöver skyddas från den allmäntrafik som brukar förekomma på kontorsnät i
allmänhet och de infektioner eller hackerattacker som kan förekomma där.
På samma sätt som man vill etablera interna skyddsbarriärer, så implementerar man
samtidigt en annan viktig säkerhetsprincip, försvar i djupled. För att nå ett av pro-
80/120
cessnäten från Internet så krävs det i detta exempel att man lyckas forcera flera nivåer
av brandväggar och skyddsmekanismer.
Figur 23 Översikt uppdelning av nätverk och interna skydd i form av brandväggar
I föregående bild visas en organisations nätverk där de olika processnäten är avgrän-
sade från det koncernnätverket med hjälp av brandväggar. Dessa brandväggar kan
vara uppsatta för att skydda de olika processnätverken, och de därtill ansluta industri-
ella kontrollsystemen eller automationssystemen, från händelser och hot som finns på
koncernnätet och kontorsnäten. Brandväggarna kan också vara uppsatta så att kon-
cernnätet, kontorsnäten, dess anslutna datorer och system är skyddade från händelser
och trafik som förekommer på processnätverken. Det sistnämnda kan vara ett krav
eller önskemål för de som är ansvariga för koncernens system och IT då det i process-
näten ibland finns externa kopplingar, exempelvis till anläggningsnät eller damm-
övervakningssystem som kan ligga utanför fysiska skalskydd eller fysiska områ-
desskydd. Denna typ av dubbelriktat skydd är ofta vanlig i kopplingar mellan process-
kontrollnät och kontorsnät.
81/120
Att införa denna typ av uppdelning av nätet i flera delar, som är har säkerhetskontrol-
ler och skydd i form av brandväggar och andra nätsäkerhetskomponenter, är ett första
steg mot att införa en zonmodell på nätverksnivå. En typmodell för ett företag i elbran-
schen har någon typ av zonmodell där produktionsdelar (elproduktion, eldistribution,
viktig infrastruktur, kritiska IT-komponenter) är skyddade.
Rekommendation I organisationer som har utrustning för automation av processer, där industriella kontroll-system används, så ska sådan utrustning separeras från vanliga kontorsdatorer och kon-torsnät. Processnätverken och dess utrustning skall skyddas från direkt åtkomst från kon-torsnät, Internet, etc. Ett företag i elbranschen bör ha en nätverkssäkerhetslösning med segmentering och upp-
delning av nät som innehåller en koppling till en zonmodell.
9.1.2 Typfall för fjärråtkomst
Detta avsnitt beskriver olika typfall för fjärråtkomst. Tidigare textstycken beskriver
bakgrund och teknik rörande fjärråtkomst. För mer information om detta, se kapitel
”Fjärråtkomst” sid 51.
Det är viktigt att fjärråtkomstlösningar är genomtänkta. Det finns flera olika sätt att
lösa fjärråtkomst på där man ställer olika för och nackdelar mot varandra.
Traditionellt, så har man haft fjärråtkomstlösningar där stationer, anläggningar och
utrustning har varit lokalt kopplade till telenätet via modem. I vissa fall har dessa er-
satts med ISDN-lösningar, lokala internetabonnemang via ADSL eller liknande.
82/120
Figur 24 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar
I de fall man har haft lokala lösningar så får man nackdelen av att dessa ofta inte är av
standardiserat snitt eller samordnade tekniskt utan ofta är av typen ”hemsnickrad”
lösning, eller att de råkade bli den lösning som leverantören av just det lokala systemet
installerat. Likaså har man inte heller någon central administration och övervakning i
en sådan distribuerad och utlokaliserad typ av lösningsarkitektur. Av dessa anledning-
ar så har många företag under senare år arbetat med att ta bort lokala kommunikat-
ionslösningar och ersätta dessa lokala modem, VPN-bryggor eller småbrandväggar
med centraliserade kommunikationslösningar.
83/120
I bilden nedan visas en typlösning där man istället för lokala modem, ISDN- eller
ADSL-routers i anläggningar och ute på lokalkontor, har installerat en central anslut-
ningspunkt i form av en VPN-gateway. Via denna enstaka centrala anslutningspunkt
så kan man ta sig in via Internet för att sedan nå olika interna nätverk och dess an-
slutna system.
Figur 25 Översiktsbild lokala fjärranslutningsmöjligheter ute i anläggningar
84/120
Rent allmänt så finns det mycket man har att vinna med en väl utformad centraliserad
lösning. Ekonomiska skalfördelar vad det gäller infrastrukturinköp och underhåll,
enklare att övervaka och administrera, standardisering av den tekniska lösningen,
m.m. De nackdelar som finns med en centraliserad lösning inkluderar beroende av IT-
teknisk infrastruktur utanför respektive anläggning samt ofta ett beroende mellan
organisationsdelar och personal.
Ett annat problem med att centralisera fjärråtkomstlösningar för alla anläggningar via
en eller ett fåtal centrala in- och utgångar för organisationen är att man kan tvingas
göra hopkopplingar av nät- och IT-lösningar som annars borde fått vara fysiskt separe-
rade eller på annat sätt ha ett starkt logiskt begränsat kommunikationsflöde. Likaså
finns det ett problem med centraliserade lösningar att dessa kan drabbas av vissa pro-
blem vid storstörningar, t.ex. att organisationens WAN-nät slås ut, då det samtidigt
finns behov av åtkomst från leverantörer som behöver komma åt utplacerad utrust-
ning för felavhjälpning, support- eller underhållsarbete.
Vilken lösning som är bäst för varje enskild organisation är svårt att ge ett generellt
arkitekturellt råd om då detta beror på många olika förutsättningar och riskbedöm-
ningar. En tanke kan vara att försöka hitta en lösning där man har standardiserad
distribuerad utrustning, såsom brandväggar och/eller VPN-gateways, som kan fungera
autonomt vid en storstörning eller problem med den centrala internetanslutningen
eller WAN-kopplingar. Samtidigt så har lösningen stöd för att man har en central
övervakning och drift av den utlokaliserade utrustningen, så att denna sköts på ett
samordnat sätt.
En annan sak som är viktig med fjärråtkomstlösningar är att kunna begränsa upp-
kopplingarna. Bara för att någon släpps över tröskeln så betyder inte det att man per
automatik skall få åtkomst till alla interna system, alla informationsresurser, alla nät-
verkstjänster eller alla applikationer. Det kan vara viktigt att man sätter upp åtkomst-
profiler, så att vissa som ansluter bara får komma åt vissa system, applikationer eller
nätverkstjänster.
Rekommendationer
Det är viktigt att fjärråtkomstlösningen är ändamålsenlig och säker. Detta gäller för var tid,
och för varje typ av extern händelse. Det är därför viktigt att fjärråtkomstlösningen utfor-
mas med hög tillgänglighet och användbarhet även under onormala driftförhållanden i den
ordinarie IT-driften.
Det är viktigt att en fjärråtkomstlösning har en bra grundsäkerhet. Med grundsäkerhet
menar vi bland annat att den alltid skall vara försedd med åtkomstkontroll (lösenord eller
85/120
motsvarande). Den skall vara inställd så den skyddar mot försök till obehöriga inloggningar
samt att den loggar sådana försök.
Det är också viktigt att en fjärråtkomstlösning fungerar när den som mest behövs, t.ex. i
samband med att man behöver hjälp från leverantörer i samband med felavhjälpning eller i
samband med en storstörning.
Sätt upp fjärråtkomstlösningen med någon typ av åtkomstprofiler så att den ger ett kon-
trollerat och begränsat sätt att komma åt interna resurser. Bara för att man gör en fjärrin-
loggning betyder inte det att man skall ha obegränsad åtkomst till interna servrar och in-
formationsresurser.
Var restriktiv med hur mycket, och vad, som exponeras och görs åtkomligt via fjärråtkomst-
sättet. Tillåt bara ett fåtal nätverksprotokoll. Exportera hellre enstaka applikationer än hela
fjärrskrivbord.
9.2 Open Security Architecture Det finns fler referensarkitektursmodeller framtagna av Open Security Architecture,
OSA. Dessa OSA-konceptet finns det flera olika fördefinierade typfall och ”mönster”
som beskriver vanliga situationer. OSA:s mönster och referensexempel kan hittas
här22. Tillhörande säkerhetskontroller finns definierade i den här23 relativt omfattande
katalogen.
Denna typ av standardlösningar med mönster gör det lätt att återanvända koncept,
teknik och lösningar och är idealiska för att förklara vinsten med att använda en sä-
kerhetsarkitektur.
I denna del av vägledningen listas ett antal säkerhetskontroller på engelska. Det är de
namn som de ges i OSA:s dokumentation. Om man besöker OSA:s webbsida24, så finns
dessa hyperlänkade och närmare beskrivna där.
I detta avsnitt lyfter vi fram några vanliga och viktiga exempel för företag och organi-
sationer i elbranschen:
1 Generell modellösning för IT-användning
2 Modellösning för skydd av servrar
3 Modellösning för brandväggar med DMZ
22 http://www.opensecurityarchitecture.org/cms/library/patternlandscape 23 http://www.opensecurityarchitecture.org/cms/library/0802control-catalogue 24 http://www.opensecurityarchitecture.org/cms/index.php
86/120
4 Modellösning för skydd och övervakning av säkerheten i industriella kontroll-
system
5 Modellösning för avancerad övervakning och detektering
Huvuddelen av dessa modellösningar beskriver IT-landskapet och innehåller många
tekniska säkerhetskontroller. Även andra säkerhetskontroller såsom administrativa
rutiner, roller och ansvar berörs.
9.2.1 Open Security Architectures generella modellösning
Följande typbeskrivning beskriver OSA:s generella IT-användarmönster25. Bilden visar
på en övergripande nivå vanliga aktörer (användare, tjänsteägare, utvecklare, tjänste-
leveransansvarig, säkerhetsansvarig eller revisor), vanliga infrastrukturkomponenter
(servrar, klienter) och vanliga säkerhetskontroller (tekniska, administrativa och orga-
nisatoriska).
25 http://www.opensecurityarchitecture.org/cms/library/patternlandscape/236-0802pattern009
87/120
Figur 26 Översiktsbild generell modellösning
Denna ovanstående generella typmodell visar att det finns ett inslag av säkerhet i de flesta fall. Och att dessa säkerhetskrav omfattar såväl krav på tekniska säkerhetskon-troller, rutiner och ansvar, mandat och roller.
9.2.2 Open Security Architectures modellösning för serversäkerhet
Följande typbeskrivning beskriver OSA:s generella typfall för att säkra upp en server26.
I detta typfall så finns det ett stort antal, både tekniska och icke-tekniska, säkerhets-
kontroller.
Typfallet är en allmän server som installerats och vars löpande drift och underhåll
skall inkludera säkerhetsfunktioner.
26 http://www.opensecurityarchitecture.org/cms/library/pattern_landscape/188-0802pattern-002
88/120
Figur 27 Översiktsbild modellösning för serversäkerhet
De sammanlagt 89 säkerhetskontroller som finns i OSA:s kontrollkatalog27 och som i
denna referensmiljö inkluderar:
> AC-03 Access enforcement
> AC-05 Separation Of Duties
> AC-06 Least privilege
27 http://www.opensecurityarchitecture.org/cms/library/0802control-catalogue
89/120
> AC-07 Unsuccessful login attempts
> AC-08 System use notification
> AC-09 Previous Logon Notification
> AC-10 Concurrent Session Control
> AC-12 Session Termination
> AT-03 Security Training
> AT-04 Security Training Records
> AU-02 Auditable Events
> AU-03 Content Of Audit Records
> AU-04 Audit Storage Capacity
> AU-05 Response To Audit Processing Failures
> AU-06 Audit Monitoring, Analysis, And Reporting
> AU-08 Time Stamps
> AU-09 Protection Of Audit Information
> AU-10 Non-Repudiation
> AU-11 Audit Record Retention
> CA-02 Security Assessments
> CA-04 Security Certification
> CA-06 Security Accreditation
> CA-07 Continuous Monitoring
> CM-02 Baseline Configuration
> CM-03 Configuration Change Control
> CM-04 Monitoring Configuration Changes
> CM-05 Access Restrictions For Change
> CM-06 Configuration Settings
> CM-07 Least Functionality
> CM-08 Information System Component Inventory
90/120
> CP-03 Contingency Training
> CP-04 Contingency Plan Testing And Exercises
> CP-05 Contingency Plan Update
> CP-09 Information System Backup
> CP-10 Information System Recovery And Reconstitution
> IA-02 User Identification And Authentication
> IA-06 Authenticator Feedback
> IA-07 Cryptographic Module Authentication
> IR-02 Incident Response Training IR-03 Incident Response Testing And Exercises
> IR-04 Incident Handling
> IR-05 Incident Monitoring
> IR-06 Incident Reporting
> IR-07 Incident Response Assistance
> MA-02 Controlled Maintenance
> MA-03 Maintenance Tools
> MA-04 Remote Maintenance
> MA-05 Maintenance Personnel
> MA-06 Timely Maintenance
> MP-02 Media Access
> PE-02 Physical Access Authorizations
> PE-03 Physical Access Control
> PE-05 Access Control For Display Medium
> PE-06 Monitoring Physical Access
> PE-09 Power Equipment And Power Cabling
> PE-10 Emergency Shutoff
> PE-11 Emergency Power
> PE-12 Emergency Lighting
91/120
> PE-13 Fire Protection
> PE-14 Temperature And Humidity Controls
> PE-15 Water Damage Protection
> PE-16 Delivery And Removal
> RA-02 Security Categorization
> RA-03 Risk Assessment
> RA-04 Risk Assessment Update
> RA-05 Vulnerability Scanning
> SA-02 Allocation Of Resources
> SA-03 Life Cycle Support
> SA-04 Acquisitions
> SA-05 Information System Documentation
> SA-06 Software Usage Restrictions
> SA-08 Security Engineering Principles
> SC-02 Application Partitioning
> SC-03 Security Function Isolation
> SC-04 Information Remnance
> SC-05 Denial Of Service Protection
> SC-06 Resource Priority
> SC-10 Network Disconnect
> SC-12 Cryptographic Key Establishment And Management
> SC-13 Use Of Cryptography
> SC-14 Public Access Protections
> SC-18 Mobile Code
> SI-02 Flaw Remediation
> SI-03 Malicious Code Protection
> SI-04 Information System Monitoring Tools And Techniques
92/120
> SI-05 Security Alerts And Advisories
> SI-06 Security Functionality Verification
> SI-07 Software And Information Integrity
> SI-10 Information Accuracy, Completeness, Validity, And Authenticity
> SI-11 Error Handling
Även fast varje server kanske inte behöver omfattas av alla dessa säkerhetskontroller
och rutiner, så är denna lista att se som en bruttolista och en startpunkt för att se hur
väl ens servrar är uppsatta i jämförelse med denna referenssäkerhetsversion av en
serverinstallation och löpande drift av den samma.
9.2.3 Open Security Architectures modellösning för en brandvägg med DMZ
Denna principskiss visar i detalj hur en så kallad demilitariserad zon, DMZ, är tänkt
att fungera. Ett DMZ sitter i anslutning till en brandvägg och är den del av nätet som
vare sig sitter på insidan eller på utsidan av brandväggen. DMZ är ett särskilt servernät
där man sätter extra utsatta serverdatorer, ofta kallade bastiondatorer, vilka huserar
tjänster. Följande mönster beskriver OSA:s referensuppsättning28 av en DMZ-
funktion.
28 http://www.opensecurityarchitecture.org/cms/library/patternlandscape/286-sp-016-dmz-module
93/120
Figur 28 Översiktsbild modellösning DMZ
De sammanlagt 31 säkerhetskontroller som finns i OSA:s kontrollkatalog29 och som
används i denna referensmiljö inkluderar:
> AC-04 Information Flow Enforcement
> AC-06 Least Privilege
> AC-07 Unsuccessful Login Attempts
> AC-12 Session Termination
> AU-02 Auditable Events
29 http://www.opensecurityarchitecture.org/cms/library/0802control-catalogue
94/120
> AU-03 Content Of Audit Records
> AU-04 Audit Storage Capacity
> AU-05 Response To Audit Processing Failures
> AU-06 Audit Monitoring, Analysis, And Reporting
> AU-07 Audit Reduction And Report Generation
> AU-08 Time Stamps
> AU-09 Protection Of Audit Information
> AU-10 Non-Repudiation
> AU-11 Audit Record Retention
> CA-03 Information System Connections
> CA-04 Security Certification
> CA-05 Plan Of Action And Milestones
> CM-07 Least Functionality
> RA-05 Vulnerability Scanning
> SC-05 Denial Of Service Protection
> SC-10 Network Disconnect
> SC-20 Secure Name / Address Resolution Service (Authoritative Source)
> SC-21 Secure Name / Address Resolution Service (Recursive Or Caching Resolver)
> SC-22 Architecture And Provisioning For Name / Address Resolution Service
> SC-23 Session Authenticity
> SI-03 Malicious Code Protection
> SI-04 Information System Monitoring Tools And Techniques
> SI-05 Security Alerts And Advisories
> SI-06 Security Functionality Verification
> SI-07 Software And Information Integrity
> SI-08 Spam Protection
95/120
På brandväggar som används i interna nätverk, exempelvis mellan processnätverk och
kontorsnätverk, så kan DMZ används för att hålla vissa tjänster som behöver åtkomst
från något av hållen. Exempel på sådana tjänster kan vara:
> uppdateringsservar, som används för att ta in programvaruuppdateringar till ope-
rativsystem eller applikationer
> databasservrar, som innehåller sparade värden, transaktioner eller långtidslagrad
information. Exempel på databaser som kan finnas placerade i DMZ är så kallade
historian-servrar.
> filöverföringsservrar, som används för att utväxla filer och information mellan
system som är placerade i kontors- och processnäten.
Rekommendation DMZ-konceptet bör användas flitigt när man segmenterar eller delar upp sitt interna nät och skyddar olika processnät och industriella automationslösningar.
9.2.4 Open Security Architectures modellösning för industriella kontrollsystem
Nedanstående bild visar en organisation som har ett kontorsnätverk med tillhörande
IT-system samt ett annat nätverk för tillverkning och automation av industriproces-
sen.
Detta exempel ger en bra förståelse för de olika skyddsbehov, olika säkerhetskontroller
och begränsningar som behövs för att skapa en grundsäkerhet i en miljö för industri-
ella kontrollsystem.
Förutom tekniska skydd så behövs många rutiner och löpande operativa säkerhetsåt-
gärder såsom exempelvis övervakning av säkerhetsrelaterade larm och loggar.
96/120
Figur 29 Översiktsbild modellösning för industriella kontrollsystem30
Bilden ovan beskriver en miljö som översiktligt visar en industriell IT-användning då
man har ett industriellt kontrollsystem som i sin tur är kopplad mot koncernnätverket.
Bilden visar att det finns flera roller som förekommer på olika delar i landskapet. En
viktig roll som också ställer till en hel del problem är fjärrsupportsanvändare. Dessa
30 http://www.opensecurityarchitecture.org/cms/library/patternlandscape/293-sp-023-industrial-control-systems
97/120
användare har, om de missbrukar IT-verktyg som de förfogar över vid fjärrsupport och
fjärruppkopplingar, möjlighet att ställa stor skada.
Historian är en databas där man har historiska data och värden för ett SCADA/ICS
eller automationssystem. Ofta är det som finns i historian sparade mätvärden eller
statusvärden.
För det första är det värt att påpeka att såsom det är ritat i detta exempel, som
är ett OSA-standardtypfall, så är Historian-systemet placerat på koncernnätet, inte i
processnätet. Det är viktigt att förstå att denna lösning inte alltid är önskvärd. En vari-
ant av detta typfall är att placera historian-servern på ett DMZ-nät som är placerat
mitt i mellan processnät och koncernnätet. En ännu mer avancerad lösning är att ha
historian-servern på processnätet och en särskild import/export-server som står på
DMZ och som används för att bereda applikationer och system på koncernnätet indi-
rekt åtkomst till historian-servern. I denna mer avancerade lösning kan man sätta upp
en lösning där man har bättre detaljkontroll och precision på vilka värden som man
ges åtkomst till. Med en sådan lösning kan exempelvis bara några få värden exporteras
från de interna systemen, eller att man bara tillåts en viss operation på dessa värden,
läsning men inte ändring.
En till detalj i detta typfall som är värt att kommentera är just fjärråtkomst. I
detta OSA-standardtypfall så är fjärråtkomstlösningen inkluderad och placerad på ett
sådant sätt att den är lokal till själva processnätet. Detta gör att fjärråtkomsten är lik-
ställd med den Engineering Workstation-dator som står på nätet. Det kan vara rätt
plats att koppla in fjärråtkomsten, men det kan också vara fel plats. Denna placering
ger en direktåtkomst in till den allra känsligaste delen av nätverket och de anslutna
PLC, RTU och den fältanslutna utrustning som finns där. I de flesta fall skulle en så-
dan fjärråtkomst anses för känslig och skulle kräva ett starkt skydd.
Ett sätt att se detta typfall är att bara se det som ett abstrakt fall och där själva bilden
med fjärråtkomst inritad i detta typfall bara skall ses som en konceptuell beskrivning
av denna funktionalitet. Det vill säga, att bilden inte skall ses som en konkret beskriv-
ning av vart man egentligen skall placera sin fjärråtkomstlösning. Så som vi diskuterat
på annat ställe i vägledningen, så är placering av fjärråtkomst något som vissa organi-
sationer har speciella placeringsalternativ eller lösningar för, exempelvis som sin stra-
tegi. För mer diskussion och information om fjärråtkomst, se kapitel ”Fjärråtkomst”
sid 51 och kapitel ”Nätverkskrypteringslösningar” sid 46.
En tredje sak som är värd att kommentera är användningen av ”informations-
nät” och ”automationsnät” i detta standardtypfall från OSA. Här finns det anslutning
98/120
från fjärråtkomst i processnätsdelen direkt in till automationsnätet, d.v.s. ”Profibus”
eller ”industriellt Ethernet”. Det är inte alltid helt önskvärt att göra denna inkoppling
av fjärråtkomstlösningen. Sannolikt vill man hellre skapa en lösning där fjärråtkoms-
ten sker via en tredje nätverksanslutning, ett DMZ.
En fjärde sak som är värd att kommentera är restriktionerna att använda tråd-
lösa nätverk och restriktionerna att använda USB-anslutna lagringslösningar (eller
andra snarlika mobila dataöverföringsmetoder)
De sammanlagt 34 säkerhetskontroller som finns i OSA:s kontrollkatalog31 och som
används i denna referensmiljö för ICS/SCADA inkluderar:
> AC-03 Access Enforcement
> AC-06 Least Privilege
> AC-17 Remote Access
> AC-18 Wireless Access Restrictions
> AU-02 Auditable Events
> CA-02 Security Assessments
> CA-07 Continuous Monitoring
> CM-02 Baseline Configuration
> CM-03 Configuration Change Control
> CM-05 Access Restrictions For Change
> CM-07 Least Functionality
> CP-02 Contingency Plan
> CP-09 Information System Backup
> CP-10 Information System Recovery And Reconstitution
> IA-02 User Identification And Authentication
> IA-03 Device Identification And Authentication
> IR-02 Incident Response Training
> IR-04 Incident Handling
31 http://www.opensecurityarchitecture.org/cms/library/0802control-catalogue
99/120
> IR-05 Incident Monitoring
> IR-07 Incident Response Assistance
> MA-02 Controlled Maintenance
> MA-04 Remote Maintenance
> PE-03 Physical Access Control
> PE-04 Access Control For Transmission Medium
> PE-06 Monitoring Physical Access
> RA-03 Risk Assessment
> RA-05 Vulnerability Scanning
> SC-07 Boundary Protection
> SC-08 Transmission Integrity
> SC-09 Transmission Confidentiality
> SC-23 Session Authenticity
> SI-02 Flaw Remediation
> SI-03 Malicious Code Protection
> SI-05 Security Alerts And Advisories
9.2.5 Open Security Architectures modellösning för avancerad övervakning och detektering
En viktig del i att ta fram en säkerhetsarkitektur är att övervaka den vanliga IT-
infrastrukturen. Nedan visas den typmodell och det mönster som OSA har tagit fram
för att beskriva övervakning och monitorering av vanliga IT-infrastrukturfunktioner
såsom fjärråtkomst, perimeterskydd (brandväggar, m.m.).
100/120
Figur 30 Översikt av typmodellen för avancerad övervakning och monitorering32
32 http://www.opensecurityarchitecture.org/cms/library/patternlandscape/314-sp-025-advanced-monitoring-and-detection
101/120
De sammanlagt 38 säkerhetskontroller som finns i OSA:s kontrollkatalog33 och som
används i denna referensmiljö för avancerad övervakning och detektering inkluderar:
> AC-02 Account Management
> AC-04 Information Flow Enforcement
> AC-17 Remote Access
> AC-18 Wireless Access Restrictions
> AC-20 Use Of External Information Systems
> AT-01 Security Awareness And Training Policy And Procedures
> AU-01 Audit And Accountability Policy And Procedures
> AU-02 Auditable Events
> AU-06 Audit Monitoring, Analysis, And Reporting
> AU-09 Protection Of Audit Information
> AT-01 Security Awareness And Training Policy And Procedures
> CA-02 Security Assessments
> CM-01 Configuration Management Policy And Procedures
> CM-02 Baseline Configuration
> CM-03 Configuration Change Control
> CM-05 Access Restrictions For Change
> CM-06 Configuration Settings
> CM-09 Configuration Management Plan
> CP-10 Information System Recovery And Reconstitution
> IR-01 Incident Response Policy And Procedures
> IR-03 Incident Response Testing And Exercises
> IR-05 Incident Monitoring
> IR-08 Incident Response Plan
> PM-06 Information Security Measures of Performance
33 http://www.opensecurityarchitecture.org/cms/library/0802control-catalogue
102/120
> RA-01 Risk Assessment Policy And Procedures
> RA-02 Security Categorization
> RA-03 Risk Assessment
> RA-05 Vulnerability Scanning
> SA-03 Life Cycle Support
> SA-06 Software Usage Restrictions
> SA-07 User Installed Software
> SA-08 Security Engineering Principles
> SC-07 Boundary Protection
> SI-03 Malicious Code Protection
> SI-04 Information System Monitoring Tools And Techniques
> SI-06 Security Functionality Verification
> SI-07 Software And Information Integrity
> SC-26 Honeypots
9.3 IEC 62443 Standarden för säkerhet i automationssystem, ISA-99, som numera är känt som IEC
62443, är en standard för ” Industrial communication networks – Network and system
security”. Dessa standarder ges ut av IEC och är upphovsrättsskyddade och kostnads-
belagda.
Just på grund av upphovsrättsskyddet har vi i detta dokument inte klippt in några
exempel såsom vi gjort med Open Security Architectures olika modellexempel och
typmönster. Likaså, på grund av IEC:s prissättningsmodell, har vi inte heller använt
IEC-standarden närmare för att på så sätt tvinga läsare att skaffa in dessa dokument,
då de är kostsamma.
I serien 62443 finns bland annat:
> Part 1-1: Terminology, concepts and models
> Part 2-1: Establishing an industrial automation and control system security pro-
gram
103/120
> Part 3-1: Security technologies for industrial automation and control systems
> Part 3-3: System security requirements and security levels
Flera delar av 62443-standarden är fortfarande under framtagande, exempelvis delen
62443-3-2 (Security Risk Assessment and System Design) och 62443-2-3 (Patch ma-
nagement in the IACS Environment) är två delar som ännu inte är helt framtagna eller
publikt tillgängliga när detta skrivs.
I del 2-1 så beskrivs processen för att införa ett CSMS, cyber security management
system, vilket är en tillämpning av att implementera ett ISMS för processkontroll- och
automationssystem.
Av dessa delar kan del 3-1 ses som en kontrollkatalog som beskriver de principiella
säkerhetskontroller som står till förfogande för skydd för ICS-lösningar och automat-
ionssystem.
Det finns många fördelar med att använda 3-1 som kontrollkatalog, bland annat:
> Att det för varje säkerhetskontroll finns en bedömning om hur just denna säker-
hetskontroll används och går att anpassa för användning i ICS-lösningar och
automationssystem.
> Att det finns ”typical deployment” som beskriver typiska användningsområden för
dessa säkerhetskontroller
> Att det för varje säkerhetskontroll finns ”recommendations and guidance” som på
en ganska detaljerad nivå ger vägledning och rekommendationer per kontroll.
Detta medför att de som skall införa olika säkerhetskontroller får god hjälp på
vägen med tolkningar och vägval.
Standarden 62443 går i många fall ner på oväntad detaljnivå och är ovanligt specifik i
många aspekter, exempelvis att den går igenom specifika säkerhetsteknologier såsom
smarta kort eller biometri. Likaså beskriver den på detaljnivå vissa komponenter och
teknologier som används inom automation, såsom realtidsoperativsystem (RTOS) och
fältkommunikationslösningar (FAN, Field Area Networks). Fördelen med detta är den
är anpassad mot just säkerhetskrav i industriella kommunikationsnät och automat-
ionslösningar.
104/120
10 Uppslagsord
Aktiv avlyssning är avlyssning som utförs med hjälp av aktiv påverkan på själva meddelandetransporten, exempelvis via en omdi-rigeringsattack vilken medför att meddelandet skickas en annan väg än avsändaren avsett och därmed också kan avlyssnas av angriparen.
Aktörsdrivna hot Betecknade även som antagonistiska hot vilka hänför
sig till medvetna fientliga handlingar/sabotage
ANSI American National Standard Institute
Angrepp Ett sätt att mot en IT-resurs göra någon typ av anfall,
attack med hjälp av olika tekniska metoder.
Antagonistiska angrepp Antagonistiska angrepp är en form av aktörsdrivna hot.
Attackvektor En attack vektor är en väg eller sätt på vilket en anta-
gonist kan få genomföra skadliga attacker mot sårbar-
heter. Angreppsvägar gör det möjligt för exempelvis
hackare att utnyttja sårbarheter i ett system vilket även
inkluderar sårbarheter som den mänskliga faktorn.
Attackyta Den yta (antal sårbarheter) som exponeras för en
antagonnist
Barriär Skyddsanordning, säkerhetskontroll eller skyddsprin-
cip som måste forceras.
Brandvägg Inom IT-teknik en säkerhetsfunktion som har som
särskild uppgift att på ett säkerhetsmässigt sätt styra,
kontrollera och rapportera datorkommunikation och
nätverkstrafik.
CA Certification Authority.
CENELEC Comité Européen de Normalisation Electrotechnique.
Europeisk standardiseringskommitté för elektroteknik
COTS (Eng. Commercial off-the-shelf). Färdiga standard-
komponenter till skillnad mot skräddarsydda produk-
ter eller leverantörsunika lösningar.
Cyberattack Alla typer av offensiva attacker utförda av enskilda eller
organisationer som har som mål enskilda datorer, IT-
infrastruktur, datornätverk eller utrustning med IT-
105/120
koppling, exempelvis styrsystem eller styrsystemskom-
ponenter.
Dataintegritet Egenskap i ett informationssystem eller hos informa-
tion med skydd mot förvanskning och oönskad
förändring
Dataintrång Brott enligt 4 kap 9c § i brottsbalken. Brottet avser den
som olovligen bereder sig tillgång till en uppgift som
är avsedd för automatisk behandling eller olovligen
ändrar, utplånar, blockerar eller i register för in så-
dan uppgift, om inte brottet uppfyller rekvisiten för
något av brotten brytande av post- eller telehemlig-
het; intrång i förvar eller olovlig avlyssning.
DCS Distributed Control System. DMZ Demilitariserad zon. Inom IT-säkerhet en benämning
på en sträcka i form av logiskt eller fysiskt nätverk som befinner sig utanför det interna nätverket och som an-sluter utrustning och nättjänster som är utsatta och ex-ponerade. Är ofta implementerat som ett tredje ben på en brandvägg som har ett externt och ett internt ben.
Elektroniskt certifikat Digital information som knyter ihop information med
en viss utställare eller utgivare Elektronisk signatur Uppgifter i elektroniskt format som är fogade till, eller
logiskt knutna till, andra elektroniska uppgifter och som används som en metod för att autentisera dessa uppgifter
ENISA European Union Agency for Network and Information
Security.
EU-myndighet för nätverks- och informationssäkerhet.
ENTSO-E European Network of Transmission System Operators
for Electricity. Samarbetsorgan för europeiska stam-
nätsoperatörer. Externt hot Hot som har sitt ursprung utanför organisationen,
verksamheten eller liknande. FAT Factory acceptance testing Fjärråtkomst Metod att på distans nå ett system, en applikation, en
utrustning eller komponent. Termen används i dessa sammanhang ofta för att beteckna extern åtkomst in mot en organisations nätverk vid exempelvis hemar-bete, jour, diagnostik- eller service av hård eller mjuk-vara.
106/120
Fysiska hot Hot som kan påverka, eller resultera i konsekvenser,
saker i den fysisk världen Fysiskt skydd Omgivande skydd av IT- system och dess resurser som
skyddar mot direkt fysisk åtkomst av obehörig.
HMI (Eng. Human Machine Interface). Människa-
maskingränssnitt, se Operatörsstation.
Historian Databas som innehåller historiska data och värden för
ett SCADA/ICS eller automationssystem. Ofta sparade
mätvärden eller statusvärden. Hot En möjlig, oönskad händelse med negativa konsekven-
ser för verksamheten IACS Industrial automation and control system. Förkortning
som återkommande används i IEC 62443-standarden för att beteckna industriella informations och styrsy-stem.
ICS (Eng. Industrial Control Systems). En vanligt före-
kommande förkortning som ibland används synonymt
med industriella informations- och styrsystem.
IEEE Institute of Electrical and Electronics Engineers. Inter-
nationell organization som arbetar med att främja in-
genjörskonst och tekniska framsteg, exempelvis genom
konferenser, standardiseringsarbete, mm.
IETF Internet Engineering Task Force. Organisation som
arbetar med att ta fram standarder, övergripande poli-
cies och nya concept för att kommunicera över Internet
och med internetteknologi. Information Ett uttryck av kunskap eller budskap i konkret form
samt innehåller ofta, men inte alltid, en samling fakta. Informationsklassning Klassning av en organisations informationstillgångar.
Är en grundläggande aktivitet och en förutsättning för att lyckas med andra säkerhetsaktiviteter och för att skapa en effektiv informationssäkerhet.
Informationsläckage Hotet att information lämnas ut av behöriga som med-
vetet överträder sina befogenheter och det förtroende som de tilldelats. Kan också vara automatiskt uthämt-ning eller utlämning, av ett program eller ett system som är felaktigt.
107/120
Informationstillgång en organisations eller persons informationsrelaterade tillgångar såsom dokument, strukturerad elektronisk och digital data, tjänster, datorer, applikationer, med mera.
Informationsstöld Stöld av informationstillgångar Informationssäkerhet Bevarande av konfidentialitet (sekretess), riktighet och
tillgänglighet hos information. Andra egenskaper såsom autenticitet, spårbarhet, oavvislighet och tillför-litlighet inbegrips vanligen också.
Intrång Oönskad interaktion med system i strid med systemets
policy eller som kan medföra förändring, störning eller skada. Det kan förekomma både fysiskt eller logiskt in-trång.
Intrångsdetekterings- system Automatiserad detektion och analys av händelser som
kan uppfattas som säkerhetsöverträdelser, intrångsför-sök eller liknande.
IP Internet Protocol IPv4 Internet protocol version 4. Den version av IP som
historiskt har använts på Internet och som använder sig av en adress av typen 123.234.123.234
IPv6 Internet protocol version 6. Den version av IP som
framtagits för att adresserna i IPv4 håller på och ta slut. IPsec Internet Protocol Security
IT Informationsteknologi (eng. Information Technology).
IT-säkerhet Säkerhet beträffande IT-systems förmåga att hindra
obehörig åtkomst, störningar, oavsiktlig eller obehörig
förändring. Att skydda en organisations värdefulla in-
formationstillgångar som information, hård- och mjuk-
vara. IT-säkerhet koncentrerar sig på hot och skydd
förenade med användning av IT.
Kapad webbsida En, ofta manipulerad eller ändrad, webbsida som över-
tagits av obehöriga. Webbsidan kan sprida nya bud-
skap, men även sprida datorvirus eller annan skadlig
kod som ovetande webbsidesbesökare smittas av.
LAN Local Area Network. Lokalt datornätverk.
NAT Network Address Translation. Adressöversättnings-
funktionalitet som översätter mellan nätverksadresser.
108/120
Metod som oftast används för att kunna använda IP-
adresser som inte är nåbara och användbara på det
publika Internet.
NIDS Nätverksbaserat intrångsdetekteringssystem (eng.
Network Intrusion Detection System). Säkerhetskon-
troll för att upptäcka och larma om säkerhetshändelser,
säkerhetsöverträdelser, policybrott och liknande utifrån
analys av nätverkstrafik. Oavsiktligt hot Hot som existerar trots att illasinnad avsikt saknas. Oavvislighet Ett skyddsmål att en handling inte i efterhand skall
kunna förnekas av utföraren. OLE Object Linking and Embedding OPC OLE for Process Control Patch Programuppdatering för att fixa enstaka eller fåtal fel i
programkod. Det finns såväl källkodspatchar som binärpatchar som utför rättningar i ursprungskällkoden respektive i redan kompilerad och installerad programvara. Att inte in-stallera en patch medför att man har en kvarvarande risk då programfelet, exempelvis ett säkerhetsrelaterat programfel, är latent och möjligt att missbruka.
PIN Personal Identification Number PKI Public Key Infrastructure PLC Programmable Logic Controller. Specialhårdvara, ofta
ett inbyggt system med nätverksåtkomst, som sköter kontrolloopar och datainsamling för automationsut-rustning. Har ofta digitala och analoga utgångar för att styra exempelvis motorer eller pumpar, eller ingångar för att ta in värden från givare.
Riktighet Skyddsmål att information inte förändras, vare sig
obehörigen, av misstag eller på grund av en funktions-störning.
Risk Kombination avsannolikheten för att ett givet hot reali-
seras och därmed uppkommande skadekostnad. RTU Remote Terminal Unit. Enklare inbyggt system för
inhämtning av värden eller styrning av fältutrustning.
SCADA Supervisory Control And Data Acquisition. Överlig-
gande, ofta geografiskt distribuerat, system för styr-
109/120
ning, kontroll och övervakning av fysiska processer.
Security by obscurity Ett vanligt förekommande problem inom säkerhets-
området. Denna term kommer av att man istället för att
skapa reell säkerhet försöker skydda systemet genom
att hemlighålla kunskap om system och tillämpningar.
Man hoppas med andra ord att säkerheten stärks ge-
nom att man döljer något, till exempel hur en viss sä-
kerhetsfunktion är implementerad.
Sekretess (eng. confidentiality) innebär att innehållet i ett in-
formationsobjekt, ibland även dess existens, inte görs
tillgängligt eller avslöjas för obehöriga. Andra namn för
sekretess är konfidentialitet och insynsskydd Skada Fel som uppstått eller orsakats vid ett särskilt tillfälle. Skadekostnad Sammanlagt värde av ett angrepps konsekvenser.
Skadlig kod (eng. malicious code). Samlingsnamn för program som
vid exekvering orsakar avsiktlig skada eller störning.
Andra namn för skadlig kod är illasinnad kod, datorvi-
rus, datavirus, malware.
Skydd Effekt av handlingar, rutiner och tekniska arrangemang
som syftar till att minska sårbarhet
Smart elnät Smarta nät är samlingen av ny teknologi, funktionen
och regelverket på elmarknaden, m.m. som på ett kost-
nadseffektivt sätt:
- underlättar introduktion och utnyttjandet av förnybar
elproduktion
- leder till minskad energiförbrukning
- bidrar till effektreduktion vid effekttoppar och
- skapar förutsättningar för aktivare elkunder.
SSH Secure Shell, protokoll och säkerhetsverktyg för att
etablera krypterade nätverkskopplingar.
SSL Secure Sockets Layer. Protokoll för att etablera krypte-
rade nätverkskopplingar. Är ersatt med det nyare pro-
tokollvarianten TLS, transport layer security.
Spårbarhet (eng. accountability) innebär att i efterhand entydigt
kunna härleda specifika aktiviteter eller händelser till
ett identifierad objekt, oftast en användare.
110/120
Sårbarhet (eng. vulnerability) Kritiskt beroende av en informat-
ionstillgång; latent brist i informationstillgång. Sårbar-
heten öppnar upp för olika typer av missbruk av in-
formationstillgången såsom dataintrång eller otillåten
behörighetseskalering.
Säker kommunikation Kommunikationsmekanismer som har kvaliteter för att
skydda överför information från avlyssning, manipulat-
ion, åverkan, återsändning, med mera. Säkerhetsarkitektur Strategiskt ramverk, byggt på en enhetlig struktur och
sammanhållande principer för de säkerhetsfunktioner som finns och den säkerhetsnivå dessa skall hålla.
Säkerhetshål svaghet i ett system som tillåter att obehöriga kan på-
verka integriteten av systemet. Säkerhetsåtgärd medel för hantering av risk, innefattandes policyer,
rutiner, riktlinjer, förfaranden eller organisationsstruk-turer vilka kan vara av administrativ, teknisk, led-ningsmässig eller juridisk karaktär.
Säkerhetschef En roll i beslutsställning som överser, styr och rådgiver
i arbetet med säkerhet inom en organisation. Säkerhetshändelse förändring av tillståndet hos en informationstillgång då
säkerheten påverkats negativt. Säkerhetsskyddsförordning Är en förordning kopplad till säkerhets-
skyddslag. Säkerhetsskyddsförordning (1996:633) som ger bestämmelser till säkerhetsskyddslagen (1996:627)
Säkerhetsskyddslag Lag som reglerar säkerhetsskydd, d.v.s. skydd mot
spioneri, sabotage och andra brott som kan hota rikets säkerhet. För mer detaljinformation se säkerhetsskydd-slagen (1996:627)
Säkerhetsskyddschef Utpekad person som utövar kontroll över säkerhets-
skyddet. Vid myndigheter skall säkerhetsskyddschefen vara direkt underställd myndighetens chef.
TCP/IP (Eng. Transmission Control Protocol / Internet Pro-
tocol). Standardiserat datakommunikationsprotokoll
som används som bärartjänster såväl på internet som
inom industriella lösningar.
Tillgänglighet (eng. availability) är möjligheten att efter behov kunna
nyttja IT- och informationstillgångar i förväntad ut-
sträckning samt inom önskad tid. Angrepp mot till-
111/120
gänglighet kallas ofta DoS-attacker, eller i större skala,
DDoS-attacker. Tillsyn Granskning som genomförs med stöd av lag och en
möjlighet för tillsynsmyndigheten att besluta om någon form av ingripande.
Tillsynsmyndighet En myndighet som utövar tillsyn över viss verksamhet,
oftast inom en viss bransch eller sektor. Trojansk häst Ett datorprogram som utger sig för en sak, men som i
själva verket har dold funktionalitet som lurar använ-dare. Se även skadlig kod
USB Universal Serial Bus Virtuellt lokalt nätverk En metod för att på nivå 2 i ett nätverk göra en logisk
uppdelning mellan olika nätverkadressrymder. Ofta kallat VLAN
Virtuellt privat nätverk En metod för att utsträcka lokala nätverk över ett
publikt nätverk, oftast i form av krypterade tunnlar. Ofta kallat VPN
VLAN (eng. Virtual Local Area Network) Se virtuellt lokalt nätverk. VPN (eng. Virtual Private Network) Se virtuellt privat nät-verk. WAN Wide Area Network. Geografiskt utspritt nätverk, ofta
över större områden såsom landsdelar eller över landsgränser.
WLAN Wireless LAN. Nätverk för att låta datorer prata med
trådlöst varandra. Ibland kallat WiFi. Baseras ofta på
variant av IEEE-standarden 802.11, som finns framta-
gen för olika överföringhastigheter.
Öppna nyckelsystem är kryptosystem där olika används beroende på om
man avser att kryptera (skydda) information eller de-
kryptera (ta bort skyddet) informationen. Den ena av
de två nycklarna – den som används för kryptering av
information – kan göras publikt tillgänglig, därav nam-
net. Öppna nyckelsystem löser ett klassiskt problem
inom kryptografik – förmedling av nycklar mellan de
parter som avser kommunicera säkert.
Öppna system Ett system som har hög grad av interoperabilitet (kan
fungera tillsammans med andra system) och portabili-
112/120
tet (fungerar på olika plattformar) samt följer öppna
standarder i hög utsträckning.
Överbelastningsattack Ett angrepp som har som avsikt att hindra normal an-
vändning, att störa eller helt slå ut funktioner och sy-
stem.
113/120
11 Referenser
CENELEC-ETSI CEN-CENELEC-ETSI Smart Grid Coordination Group
Smart Grid Reference Architecture http://ec.europa.eu/energy/gas_electricity/smartgrids/doc/xpert_group1_reference_architecture.pdf
ENISA (2013) Smart Grid Threat Landscape and Good Practice
Guide, utgiven 9 December 2013. http://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/sgtl/smart-grid-threat-landscape-and-good-practice-guide/at_download/fullReport
ENISA (2012a) Appropriate security measures for smart grids. Guide-
lines to assess the sophistication of security measures implementation [2012-12-06]. European Network and Information Security Agency. http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-infrastructure-and-services/smart-grids-and-smart-metering/appropriate-security-measures-for-smart-grids
ENISA (2012b) Smart Grid Security. Annex II. Security aspects of the
smart grid. (Deliverable – 2012-04-25). http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-infrastructure-and-services/smart-grids-and-smart-metering/ENISA-smart-grid-security-recommendations
ENISA (2012c) Smart Grid Security. Recommendations for Europe and
Member States. Deliverable – 2012-07-01). http://www.enisa.europa.eu/activities/Resilience-and- CIIP/critical-infrastructure-and-services/smart-grids-and-smart-metering/ENISA-smart- grid-security-recommendations
ENISA (2012d) Smart Grid Security. Annex V. Related initiatives. (De-
liverable – 2012-03- 31). European Network and In-formation Security Agency. http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-infrastructure-and- services/smart-grids-and-smart-metering/ENISA-smart-grid-security-recommendations
IAEA (2011) Computer Security at Nuclear Facilities
IAEA Nuclear Security Series No. 17
114/120
http://www-pub.iaea.org/MTCD/Publications/PDF/Pub1527_web.pdf
SS-ISO/IEC TR 27002 Informationsteknik – Säkerhetstekniker – Riktlinjer
för informationssäkerhetsa ̊tgärder (ISO/IEC 27002:2013, IDT)
ISO/IEC TR 27019 Information technology — Security techniques — In-
formation security management guidelines based on ISO/IEC 27002 for process control systems specific to the energy industry
IEC/TS 62443-1-1 Part 1-1: Industrial communication networks
– Network and system security – Terminology, concepts and models
Edition 1.0 2009-07 IEC 62443-2-1 Part 2-1: Industrial communication networks
– Network and system security – Establishing an industrial automation and control system security program Edition 1.0 2010-11
IEC/TR 62443-3-1 Part 3-1: Industrial communication networks
– Network and system security – Security technologies for industrial automation and control systems Edition 1.0 2009-07
IEC 62443-3-3 Part 3-3: Industrial communication networks
– Network and system security – System security requirements and security levels Edition 1.0 2013-08
Myndigheten för Vägledning till ökad säkerhet i industriella Samhällsskydd och kontrollsystem Beredskap (2009) https://www.msb.se/sv/Produkter--
tjanster/Publikationer/Publikationer-fran-MSB/Vagledning-till-okad-sakerhet-i-industriella-kontrollsystem/
Myndigheten för Stuxnet – IT som vapen eller påtryckningsmedel Samhällsskydd och https://www.msb.se/RibData/Filer/pdf/26068.pdf Beredskap (2011)
Myndigheten för Vägledning för risk- och sårbarhetsanalys
samhällsskydd och https://www.msb.se/RibData/Filer/pdf/25893.pdf
beredskaps (2011)
115/120
Myndigheten för Vägledning till ökad säkerhet i industriella Samhällsskydd och informations och styrsystem Beredskap (2014) https://www.msb.se/RibData/Filer/pdf/27425.pdf Myndigheten för Vikten av var och när - Samhällets beroende av Samhällsskydd och korrekt tids- och positionsangivelse Beredskap (2014) https://www.msb.se/RibData/Filer/pdf/27480.pdf NIST (2013a) Guidelines for Smart Grid Cybersecurity:
Vol. 1, Smart Grid Cybersecurity Strategy, Architec-ture, and High-Level Requirements http://csrc.nist.gov/publications/drafts/nistir-7628-r1/draft_nistir_7628_r1_vol1.pdf
NIST (2013b) Guidelines for Smart Grid Cybersecurity:
Vol. 2, Privacy and the Smart Grid http://csrc.nist.gov/publications/drafts/nistir-7628-r1/draft_nistir_7628_r1_vol2.pdf
NIST (2013c) Guidelines for Smart Grid Cyber Security:
Vol. 3, Supportive Analyses and References http://csrc.nist.gov/publications/drafts/nistir-7628-r1/draft_nistir_7628_r1_vol3.pdf
NIST (2013d) Security and Privacy Controls for Federal Information
Systems and Organizations http://dx.doi.org/10.6028/NIST.SP.800-53r4
Samordningsrådet för Rapport rörande säkerhet i smarta elnät smarta elnät http://www.swedishsmartgrid.se/publication/
download/rapport-rorande-sakerhet-i-smarta-elnat
Svenska kraftnät (2005) Vägledning säkerhetsanalys
http://www.svk.se/Global/01_Om_oss/Pdf/Sakerhets
skydd/Sakerhetsanalys.pdf
Svenska kraftnät (2008) Vägledning för el- och teletekniskt utförande i stations-
anläggningar i elnät
http://svk.se/Global/07_Tekniska_krav/Pdf/120327-
vagledning-el-och-teletekniskt-utforande-
stationsanlaggningar.pdf
Svenska kraftnät (2010) Tekniska riktlinjer IT-säkerhet TR04-02-B
http://www.svk.se/PageFiles/41244/TR%204-02-B.pdf
116/120
Svenska kraftnät (2011) Förstudierapport Svenska kraftnät 2011 – branschens behov av stöd inom informationssäkerhetsområdet, daterad 2012-03-26 Dnr: 2011/1199 http://www.svk.se/Global/02_Press_Info/Pdf/120326-SvK-Forstudierapport-ISIT-Sak.pdf
Svenska kraftnät (2013) Hotkatalog för Elbranschen: Hot mot IT-, informat-
ionshantering, processkontroll och automation. Version 1.0 http://www.energisakerhetsportalen.se/media/1040/Hotkatalog-fo%C2%A6%C3%AAr-Elbranschen-MASTER.pdf
Svenska kraftnät (2014) Vägledning informations- och IT-säkerhet samt säker-hetsskydd, Mars 2014 http://www.svk.se/Global/07_Tekniska_krav/Pdf/Vagledningar/vaegledning-informations-och-it-saekerhet-samt-saekerhetsskydd.pdf
OSA http://www.opensecurityarchitecture.org/ Shariatia mfl “Enterprise information security, a review of architec-
tures and frameworks from interoperability perspec-tive” - Marzieh Shariatia, Faezeh Bahmania, Fereidoon Shamsa http://ac.els-cdn.com/S1877050910004643/1-s2.0-S1877050910004643-main.pdf?_tid=b6c3845c-3cc8-11e4-9130-00000aacb361&acdnat=1410779528_8f608d03b9a5c0bce7da3bad81a3d346
117/120
12 Sakregister
3 3G....................................................... 69 4 4G ...................................................... 69 6 62443 ................................................ 102 8 802.1X ............................................... 42 A Active Directory .................................35 ADSL ................................................... 81 Aktörsdrivna hot .............................. 104 Angrepp ............................................ 104 ANSI ................................................. 104 Antagonistiska angrepp ................... 104 Applikationsövervakning .................. 36 Attackyta........................................... 104 Autentiseringstjänster ...................... 29 B BaaS .................. Se Backup as a Service Backup as a Service ........................... 20 Baklängeskonstruktion ..................... 62 BankID .............................................. 58 Barriär .............................................. 104 bastiondator ...................................... 92 Bevakningscentral .............................. 77 Blåtand .............................................. 69 Brandvägg ................................. 38, 104 Brandväggar ...................................... 29
som inte administreras internt ..68
som inte kan analysera nättrafik67
som inte loggar rätt .................... 67
som inte stödjer rätt
nätverkstrafik ......................... 67
som släpper igenom för mycket
trafik ........................................ 67
C CA ................ Se Certification Authority CENELEC ......................................... 104 CERT.SE ............................................ 64 Certification Authority ..................... 104 certifikat
hårda ........................................... 58
COTS ................................................. 104 CSMS ... Se cyber security management
system, Se Cyber Security Management System
cyber security management system 103 Cyber Security Management System 28
Cyberattack ...................................... 105 D Data Loss Prevention ........................ 38 Dataintegritet ................................... 105 DIAMETER ........................................ 65 DLP ................. Se Data Loss Prevention DMZ ................................................... 92 Driftcentral ........................................ 77 E EAPOL ................................................ 42 Elektronisk signatur ........................ 105 elektroniska certifikat
lagrade på fil .............................. 58
Elektroniskt certifikat ..................... 105 Engångslösenord ............................... 57 ENISA .............................................. 105 Enterprise Architecture ..................... 13 ENTSO-E ......................................... 105 Envägskommunikation ..................... 54 Externt hot ....................................... 105 F FAN ................. Se Field Area Networks Field Area Networks ........................ 103 Firmware ............................................ 66 Fjärråtkomst .................................... 105 Flergångslösenord ............................. 57 Fysiska hot ....................................... 106 Fysiskt skydd ................................... 106 försvar i djupled ................................. 79 G GSM .................................................... 69 H Historian .................................... 95, 106 HMI ............................................ 97, 106 Hot.................................................... 106
Aktörsdrivna ............................. 104
Externt ...................................... 105
oavsiktligt ................................. 108
I IaaS .......... Se Infrastucture as a Service IACS ...... Se Industrial automation and
control system ICS-CERT ........................................... 64 IEC 62443 ........................................ 102 IEEE ................................................. 106 IETF ...... Se Internet Engineering Task
Force Industrial automation and control
system .......................................... 106 Information ...................................... 106
118/120
Information Security Management System ........................................... 28
Informationsklassning ..................... 106 Informationsläckage ........................ 106 Informationsstöld ............................ 107 Informationssäkerhet ...................... 107 Informationsteknologi ..................... 107 Informationstillgång ........................ 107 Infrastucture as a Service ................. 20 Innehållskontroll ............................... 41 International Society of Automation 28 Internet Protocol .............................. 107 Internet Protocol Security ............... 107 Intrång .............................................. 107 Intrångsdetekteringssystem ............ 107
nätverksbaserade........................ 38
Intrångspreventeringssystem ........... 44 nätverksbaserade........................ 38
Inventering av informationstillgångar ................................................. 60, 61
IP Se Internet Protocol IPsec ....... Se Internet Protocol Security IPv4 ............................................. 67, 107 IPv6 ............................................. 67, 107 ISA .............. Se International Society of
Automation ISA-99............................................... 102 ISDN ................................................... 81 ISMS ............... Se Information Security
Management System IT Se Informationsteknologi IT-arkitektur ...................................... 13 IT-säkerhet ....................................... 107 IT-säkerhetsarkitektur....................... 13 K Kapad webbsida ............................... 107 Katalog med olika säkerhetskontroller
........................................................ 15 Katalogtjänster ............................ 29, 34 Kerberos ............................................ 34 Klassning av information ........... 60, 61 Klassningsmodell ............................... 61 kompetenscenter för IT-säkerhet..... 64 komplexa lösenord ............................. 57 Källkodsgranskning .......................... 62 L LAN ................... Se Local Area Network Larm
applikations- ......................... 33, 37
från kringutrustning............. 33, 37
från lagringssystem .............. 33, 37
från nätverksutrustning ....... 33, 37
från stödfunktioner .............. 33, 37
system- .................................. 33, 37
lasttester ............................................. 71 LDAP .................................................. 35 Ledningssystem för
informationssäkerhet .............. 18, 28 LIS ..................... Se Ledningssystem för
informationssäkerhet, Se ledningssystem för informationssäkerhet
Local Area Network ......................... 107 Loggar
• Att loggar inte sparas tillräckligt
länge ........................................ 71
Att det inte är rätt information
som loggas............................... 71
Att loggar inte går att läsa tillbaka
från säkerhetskopior .............. 72
Att loggar inte är fullständiga .... 71
Loggservrar ........................................ 29 Lösenord ............................................ 57 M Modell
zon ............................................... 52
Modem ............................................... 81 Molntjänst .......................................... 20 Mönsterkatalog .................................. 15 N NAC .................................................... 42 NAT .. Se Network Address Translation Network Address Translation ......... 107 Network time protocol ...................... 30 NIDS ....................... Se Nätverksbaserat
intrångsdetekteringssystem NIST SP800-53 ................................. 60 NTP .............. Se network time protocol Nätverksbaserade
intrångsdetekteringssystem ......... 38 Nätverksbaserade
intrångspreventeringssystem ....... 38 Nätverksbaserat
intrångsdetekteringssystem ....... 108 Nätverkskrypteringslösningar .......... 38 Nätverksövervakning ........................ 36 O Oauth .................................................. 58 Oauth2 ............................................... 58 Oavsiktligt hot ................................. 108 Oavvislighet ..................................... 108 Object Linking and Embedding ...... 108 OLE Se Object Linking and Embedding
119/120
OLE for Process Control ................. 108 OPC ........... Se OLE for Process Control Open Security Architecture ........ 24, 85 OpenID .............................................. 58 operativa
säkerhetsövervakningscentralen . 64 OSA . Se av Open Security Architecture,
Se Open Security Architecture OSI ..................................................... 69 P PaaS ................ Se Platform as a Service Patch ................................................ 108 Perimeterskydd ................................. 39 Personal Identification Number .... 108 Personuppgiftslag .............................. 19 PIN Se Personal Identification Number PKI ..... Se Public Key Infrastructure, Se
publika nyckellösningar Platform as a Service ........................ 20 PLC ........... 79, Se Programmable Logic
Controller Prestandatester .................................. 71 Problem
zonmodellen ...............................68
Programmable Logic Controller ..... 108 Projektplats ....................................... 20 Public Key Infrastructure ............... 108 Publika nyckellösningar .................... 57 PuL ................... Se personuppgiftslagen R RADIUS ....................................... 34, 65 realtidsoperativsystem .................... 103 Regressionstester ............................... 71 Remote Terminal Unit .................... 108 Riktighet .......................................... 108 Risk .................................................. 108 Risk- och sårbarhetsanalys ......... 60, 61 RTOS ........... Se realtidsoperativsystem RTU.............. Se Remote Terminal Unit S SaaS ................... Se System as a Service SAML ................................................. 58 SASBSA Se Sherwood Applied Business
Security Architecture SCADA 79, Se Supervisory Control And
Data Acquisition Secure Shell ...................................... 109 Secure Sockets Layer ....................... 109 Security Operations Centre .............. 64 Sekretess ........................................... 109 seriell kommunikation ...................... 69 Server
logg .............................................. 29
tid................................................ 29
Sherwood Applied Business Security Architecture ................................... 27
Skada ................................................ 109 Skadekostnad ................................... 109 Skadlig kod....................................... 109 Skydd ................................................ 109 Skydd mot skadlig kod ...................... 64 Smart elnät....................................... 109 Smarta elnät ....................................... 77 SOC ....... Se Security Operations Centre Spårbarhet ....................................... 109 SSH ................................ Se Secure Shell SSL ................. Se Secure Sockets Layer Stora loggvolymer .............................. 72 Stuxnet ................................................. 9 Supervisory Control And Data
Acquisition ................................... 108 syslog .................................................. 32 System as a Service ............................ 20 Systemövervakning ........................... 36 Sårbarhet.......................................... 110 Säker kommunikation ..................... 110 Säkerhetsanalys .......................... 60, 62 Säkerhetsarkitektur ......................... 110 Säkerhetschef ................................... 110 Säkerhetsgranskningar .............. 60, 62 Säkerhetshål .................................... 110 Säkerhetshändelse ........................... 110 Säkerhetskontroller ........................... 15 Säkerhetsprincip
Begränsningspunkter ................. 14
Försvar i djupled ......................... 14
Lägsta privilegienivå .................. 14
Skydd vid källan ......................... 14
Spårbarhet i varje steg av
hanteringen ............................. 14
Säkert tillstånd vid fel ................ 14
Varierat skydd ............................. 14
Säkerhetsramverk Open Security Architecture ....... 24
The Open Group Architectural
Framework ............................. 24
Säkerhetsskyddschef ....................... 110 Säkerhetsskyddsförordning ............ 110 Säkerhetsskyddslag .................... 19, 110 Säkerhetstester .................................. 63 Säkerhetsåtgärd ............................... 110 T TACACS ........................................ 34, 65 TCP/IP ............................................. 110
120/120
Tester lasttester ..................................... 71
prestandatester ........................... 71
regressionstester ........................ 71
The Open Group Architectural Framework .................................... 24
Tidhållning ........................................ 30 Tidsservrar ........................................ 29 Tillgänglighet ................................... 110 Tillsyn ................................................ 111 Tillsynsmyndighet ............................ 111 TOGAF ................... Se The Open Group
Architectural Framework Trojansk häst ..................................... 111 V,W WAN ................. Se Wide Area Network Wide Area Network ........................... 111 WiFi ............................................. 69, 111 WiMax ............................................... 69 Windows XP SP2 ............................... 72 Virtualisering .................................... 68 Virtuellt lokalt nätverk...................... 111 Virtuellt privat nätverk ..................... 111 Viruskontroll
Svartlistor ................................... 65
Vitlistor ....................................... 65
VLAN ................................................. 46 WLAN ................................................ 111 VPN .................................................... 111 WSUS ..................................................35 X X as a service ..................................... 20 XaaS ....................... 77, Se X as a service
XaaS-lösningar .................................. 68 Z ZigBee ................................................. 69 Zoninstans ......................................... 52 Zonmodell .......................................... 52
bestämma vad som är skyddsvärt
................................................ 68
Burtonmodellen .......................... 54
ej helt genomförd....................... 68
För stora zoner ........................... 69
IT-miljö utanför egen kontroll .. 68
koncentrisk ................................. 53
korsa flera zongränser ............... 69
kortsluts ..................................... 69
Oklara ansvarsförhållanden ...... 69
Sub-zoner .................................... 52
zoninstans ................................... 52
Å Åtkomstkontroll på nätverksnivå ..... 38 Ö Öppna nyckelsystem......................... 111 Öppna system ................................... 112 Överbelastningsattack ...................... 112 Övervakning ....................................... 35
applikations- .............................. 36
av säkerhetshändelser ................ 37
nätverks- .................................... 36
system- ....................................... 36
Övervakningszon ............................... 54