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

2/120

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