Bilaga 1 till Svenska Kraftnäts vägledning om IT ... · 1/54 Bilaga 1 till Svenska Kraftnäts vägledning om IT-säkerhetsarkitektur – Krav på IT-säkerhet vid installation/upphandling/projektering

1/54

Bilaga 1 till Svenska Kraftnäts vägledning om IT-säkerhetsarkitektur – Krav på IT-säkerhet vid installation/upphandling/projektering av automationslösningar i anläggningar och industriell miljö

IT-säkerhetskrav för installation/upphandling/projektering av industriella miljöer

2/54

Revisionshistorik

Version Datum Författare Kommentar

1.0 2015-11-17 Robert Malmgren Ändringar enligt kommentarer från granskare inom projektet.

0.9 2015-11-09 Robert Malmgren Första utkast till projektet


3/54

Innehållsförteckning 1 Introduktion ............................................................................................ 5

1.1 Bakgrund .................................................................................................................... 5

1.2 Fokusområdet – anläggnings-IT, kontrollsystem ....................................................... 5

1.3 Målgrupp .................................................................................................................... 6

1.4 Dokumentets utformning ............................................................................................ 6

1.4.1 Mottagare av krav ................................................................................................... 7

1.4.2 Kravtyper ................................................................................................................ 7

1.5 Normativa hänvisningar ............................................................................................. 7

1.5.1 Tillämpliga normer och riktlinjer ........................................................................... 8

1.5.2 Kopplingar mot andra dokument ............................................................................ 8

2 Undantagshantering ............................................................................... 9

3 Organisationens eget åtagande ............................................................. 10

4 Leverantorens atagande........................................................................ 11

4.1 Tillgång till information och IT-infrastruktur .......................................................... 11

4.2 IT-säkerhetstester och granskning av leverabler ...................................................... 11

4.3 Hantering av säkerhetspaverkande fel och sarbarheter ............................................ 13

4.4 Legala krav ............................................................................................................... 14

5 Arkitektur och principer ....................................................................... 15

5.1 Lösningens uppfyllnad av säkerhetsprinciper .......................................................... 16

6 Standarder ............................................................................................ 18

7 Programvara ......................................................................................... 19

8 Programmering .................................................................................... 20

9 Kommunikation ................................................................................... 21

9.1 Kommunikationsinfrastruktur .................................................................................. 21

9.2 WAN-kommunikation och kommunikation via publika/semipublika

transmissionsnät ................................................................................................................... 22


4/54

9.3 LAN-kommunikation ............................................................................................... 22

9.4 Integration och informationsutbyte .......................................................................... 23

9.5 Fjärratkomst ............................................................................................................. 24

10 Datalagring ........................................................................................... 26

11 Behorighetssystem och behorighetshantering ...................................... 27

12 Sparbarhet ............................................................................................ 28

12.1 Spårdata .................................................................................................................... 28

12.2 Tid och tidshantering ................................................................................................ 28

13 Specifika säkerhetsfunktioner .............................................................. 30

13.1 Skydd mot skadlig kod ............................................................................................. 30

13.2 Intrangsdetektering ................................................................................................... 31

13.3 Övervakning ............................................................................................................. 32

13.4 Envägskommunikation ............................................................................................. 33

13.5 Programuppdateringar och programfixar ................................................................. 33

13.6 Incidenthantering ...................................................................................................... 34

13.7 Kontrollutrustning och ändutrustning ...................................................................... 35

13.8 Extern IT-utrustning ................................................................................................. 36

13.9 Externa tjänster ......................................................................................................... 36

13.10 Fysiskt skydd ........................................................................................................ 37

14 Dokumentation ..................................................................................... 39

15 Utbildning ............................................................................................ 41

16 Revision ............................................................................................... 42

17 Ordlista ................................................................................................. 43

18 Referenser ............................................................................................ 49

19 Sakregister ............................................................................................ 52


5/54

1 Introduktion

1.1 Bakgrund Denna vägledning är en sammanställning av krav, regler, principer och rutiner som gäller i samband

med införskaffning av ny IT- utrustning, ny programvara, nybyggnation av anläggningar och

elproduktions- eller eldistributionsutrustning. Dokumentet bygger ursprungligen på en teknisk

riktlinje, TR 04-02, vilket är kravdokument framtagna av affärsverket Svenska Kraftnät (SvK) för att

skydda Svenska Kraftnats verksamhet och samhallsviktig infrastruktur mot oavsiktliga händelser såväl

som avsiktliga angrepp samt säkerställa verksamhetens kontinuitet. Då tekniska riktlinjer är publikt

tillgängliga, så används dessa ofta av företrädare i svenska elbranschen som förlaga för att upprätta

egna krav och beställningsunderlag.

TR04-02 framarbetades 2009 och publicerades 2010. Det har vid framtagandet av detta dokument

förflutit mer än 5 år. Fem år får i IT-sammanhang får anses vara en lång tid då det under tidsperioden

skett ett antal ändringar i de underliggande tekniska lösningarna såväl som att hotbild ändrats

markant under denna period.

Den tekniska riktlinjen och sedermera också denna vägledning, togs fram för att etablera ett

grundskydd för kritiska IT- och OT-komponenter. Ett grundskydd skapas genom att organisationen

kravställer mot leverantörer och entreprenörer så att de komponenter som levereras håller en

godkänd miniminivå samt att leverantören har vissa underhållsåtaganden som fokuserar på IT-

säkerhet.

Detta dokument är ett underlag för att skapa kravställande dokument, främst upphandlingsunderlag,

projektspecifikationer och liknande. Texten är i vissa fall allmänt hållen, men detta är något som

måste anpassas och preciseras när detta underlag slutligen omvandlas till del av ett avtal.

1.2 Fokusområdet – anläggnings-IT, kontrollsystem

Aktiv anläggningsutrustning består till allt större del pa digitalteknik och datorer. Denna

anläggningsutrustning och kontrollsystem och tillhörande datorsystem nyttjar i större utsträckning

allmanna defacto eller etablerade internationella standarder för hardvarukomponenter, mjukvara

och kommunikationsprotokoll. Kundkrav pa informationsutbyte, s.k. integration, med administrativa

IT- lösningar samt den tekniska utvecklingen har drivit fram dessa standardlösningar. Effekten av

detta blir att vissa principer och rutiner som gäller för administrativ IT även måste överföras att gälla

på den utrustning som används i anläggningar. De speciella krav och förutsättningar som gäller i

anläggningar innebär dock att vissa nya krav och regler måste hanteras samt att några av de

överförda principerna och rutinerna måste anpassas.

Anlaggnings-IT anvands som en del av fysiska processer där felaktigheter, missbruk eller aktiva

angrepp kan leda till direkta fel i eldistributionen, medföra personskador eller leda till skador på

anläggning och utrustning. IT används ocksa i skydds- utrustning för skydda anlaggningar och

utrustning på ett säkert sätt. När IT används för skyddsfunktioner ar det extra viktigt att IT-

sakerheten ar god, eller att skydds- funktionerna halls logiskt eller fysiskt separerade fran andra IT-

komponenter. IT i industriella sammanhang innebär ofta sarskilda förutsattningar. En viktig aspekt ar


6/54

att system eller komponenter nyttjas under lång tid. Detta påverkar behovet att fa in skydd och

säkerhetsfrågor i IT-lösningarna rätt från början. Arkitekturella fel eller grundläggande designmissar

kan sällan ändras efter drifttagning eftersom särskilda omständigheter gäller vid underhåll av IT-

baserade komponent i driftsatta anläggningar.

Att upprätthålla ett grundskydd i de digitala systemen kräver aktiva insatser under planerings- och

föreberedelsefaser, projektfas, aktiv produktion samt under utfasning eller reservdelsersättning.

Eftersom säkerhet i sig är en process, så avslutas inte säkerhetsarbetet i samband med projektavslut.

Ansvaret för detta upprätthållande faller till delar på beställarorganisationen och dess förvaltarroll,

dels på leverantören genom kontraktsåttaganden.

De skyddsåtgärder som framgår av denna vägledning skall förebygga och ge skydd mot, bland annat:

Förlust av systemtillgänglighet eller funktionalitet

Påverkan som leder till systemintegritet eller dataintegritet längre inte kan uppnås eller garanteras

Intrång, obehörigt användande

Obehörig informationsåtkomst

Spridning av skadlig kod

Denna vägledning innehåller enbart vissa delar om skydd för fysiska hot, då fokus är på logiska hot.

Vissa fysiska skyddskrav, som skydd mot obehörig anslutning mot kommunikationsnät eller fysiskt

skydd mot manipulation och åtkomst av IT- utrustning omfattas av denna text.

1.3 Målgrupp

Målgrupper för detta dokument inkluderar följande roller och ansvarsområden:

Projektledare, tekniska projektansvariga, tekniska projektspecialister inom projekt som verkar inom elverksamhet

Säkerhetsansvariga inom elverksamhet som har att kravställa vid upphandling, nyinstallation, modernisering eller förändringar i eltekniska anläggningar

Säkerhetsskyddsansvariga inom elverksamhet

Tekniska specialister inom IT som arbetar med kravställning mot industriella kontrollsystem eller anläggnings-IT

Tekniska specialister och ingenjörer inom processkontroll som arbetar med kravställning mot anläggningar eller elteknik där IT har ett visst inslag.

Andra beställaransvariga som skall ge underlag till linjeorganisation eller projekt i samband med upphandling, nyinstallation, modernisering eller förändring i eltekniska anläggningar

Målgruppen kan också uttrycks att vara alla som tillhandahåller IT- baserade system utanför

ordinarie kontors-IT-miljö, såsom exempelvis datorbaserade kontrollsystem, mätutrustning,

datorbaserade system för fysiskt anläggningsskydd (passagesystem, larm, kameraövervakning, etc.),

med mera.

1.4 Dokumentets utformning

Dokumentet är huvudsakligen uppdelat i fyra delar:


7/54

Introduktion och övergripande beskrivning

Kravdel

Ordlista

Referenser

Sakregister

Majoriteten av arbetet med framtagandet samt huvuddelen av informationen ligger I själva

kravdelen av dokumentet.

1.4.1 Mottagare av krav

Det finns ett omfattande kravbatteri i detta dokument. Kraven skall användas som underlag och

inspiration i samband med nyinstallation, förändringar och uppgraderingar av existerande lösningar,

med mera. Kraven riktas mot:

1. Främst Leverantörer, entreprenörer, implementatörer, integratörer eller andra som förser den kravställande organisationen med utrustning och tjänster

2. I vissa få fall, mer relaterade till hur en leverans skall förvaltas över tid, är riktade mot egna projekt, projektdeltagare och linjeorganisation

1.4.2 Kravtyper

I detta dokument används främst tre typer av sätt att ställa krav:

Skall-krav

Bör-krav

Redovisa-krav

Majoriteten av kraven i dokumentet är ”skall” och ”bör”-krav.

I visa fall sa förekommer det ocksa krav i samband med negation, sasom “skall inte”.

För varje organisation där denna bilaga till vägledningen om IT-säkerhetsarkitektur kan komma till

användning, så är det viktigt att anpassa krav och kravnivåer utifrån den egna organisationens

gällande säkerhetskrav och de externa krav som ställs på den egna organisationen.

Det kan finnas krav i detta dokument som är uttryckta som ”skall”-krav som måste justeras till att

vara ”bör”- eller ”redovisa”-krav. Detta är extra viktigt i de fall då en organisation skall göra en

offentlig upphandling och ”skall”-kraven kan vara diskvalificerande för en leverantör.

1.5 Normativa hänvisningar

Vid utformning av IT-system och digital anläggningsutrustning gäller följande publikationer i senaste

utgåva.


8/54

1.5.1 Tillämpliga normer och riktlinjer

Texten följer i möjligaste mån det vokabulär och de normer som beskrivs i:

SIS HB550 – SIS Handbok 550 Terminologi för informationssäkerhet

SS-ISO/IEC 27000:2014 Informationsteknik – säkerhetstekniker – Ledningssystem för informationssäkerhet – Översikt och terminologi

SS-ISO/IEC 27001:2014 Informationsteknik – säkerhetstekniker – Ledningssystem för informationssäkerhet - krav

SS-ISO/IEC 27002:2014 Informationsteknik – säkerhetstekniker- Riktlinjer för informationssäkerhetsåtgärder

ISO/IEC TR 27019:2013 Information technology — Security techniques — Information security management guidelines based on ISO/IEC 27002 for process control systems specific to the energy utility industry

IEC 62443-1

För mer information om dessa dokument, se sektionen ”18 Referenser” sid 49 i dokumentet som

listar referenser.

1.5.2 Kopplingar mot andra dokument

Det finns kopplingar mellan detta dokument och en mängd andra dokument, främst:

Svenska kraftnäts Vägledning Informations- och IT-säkerhet samt säkerhetsskydd.

Svenska kraftnäts IT-säkerhetsarkitektur – en vägledning för elbranschen med typexempel och referenslösningar.

SS-ISO/IEC 27002:2014 Informationsteknik – säkerhetstekniker- Riktlinjer för informationssäkerhetsåtgärder

Då detta dokument är en bilaga till Svenska Kraftnäts dokument ”IT-säkerhetsarkitektur – en

vägledning för elbranschen med typexempel oh referenslösningar”, sa finns det manga naturliga

kopplingar till detta dokument. Främst så finns det en mängd korsreferenser till stycken som

beskriver teknik och bakgrund till vissa av de krav som förekommer i denna kravsamling.

Detta dokument är särskilt kopplat mot kapitel 14 i 27001:2014 ”anskaffning, utveckling och

underhall av system”, inte minst 14.1.1 ”analys och specifikation av informationssäkerhetskrav”.

För mer information om dessa dokument, se sektionen i dokumentet som listar referenser.


9/54

2 Undantagshantering Det bör finnas en hantering av undantag från säkerhetskraven, för de fall da dessa riktlinjer inte kan

följas. Då bör undantaget dokumenteras samt motivationen och beskrivningarna av konsekvenser

eller effekter av att säkerhetsfunktionen inte används beskrivas närmare.

En sådan rutin kan vara utformat såsom följer:

Krav 3.1.1

Undantag fran regelverket skall för varje enskilt undantag beslutas av IT- säkerhetschef

och driftchef i samrad.

Krav 3.1.2

Beslutet skall föregås av en analys av vilka hot som kvarstar samt vilka risker som

beställaren löper pa grund av undantaget.

Krav 3.1.3

Undantaget skall nogsamt dokumenteras i relevant framtagen dokumentation

(systemdokumentation, etc.)

Krav 3.1.4

Driftansvariga för system/anlaggning eller motsvarande skall informeras om vilka

undantag fran IT-säkerhetskraven som tagits.

Om beställarorganisationen redan har en etablerad process för att hantera undantag från

informationssäkerhets- eller cybersäkerhetsregler, så bör dessa användas istället för ovan listade

krav.


10/54

3 Organisationens eget åtagande

Den egna organisationens atagande omfattar att:

Kunna bestamma, samt godkanna, eventuella avsteg fran styrdokument, såsom säkerhetskravställningar eller IT-arkitektur.

Tillsammans med leverantör ta fram underlag för att bestamma niva pa skydd.

Som ett viktigt moment att första vilka hot som existerar, vilka skydd som är viktiga att införa, vilka

informationsutbytesmässiga eller systemtekniska beroenden som existerar, så skall det utföras en

risk- och sårbarhetsanalys. Analysen skall göras av den tilltankta upphandlade lösningen och det

systemmiljö med vilket denna skall samexistera och samverka.


11/54

4 Leverantorens åtagande Som en del av ett atagande gäller det att redogöra för ingående (mjukvaru- och hårdvaru)

komponenter, dess kritikalitet för övergripande systemfunktionalitet, och komponenters IT-

säkerhetsmässiga egenskaper.

Sammanfattande, för hela detta dokument, är att leverantören/implementatören skall i sin lösning

se till att IT-skydd och IT-säkerhetsfunktioner är en vital del av levererad lösning.

4.1 Tillgång till information och IT-infrastruktur

Den information som tillhandahålls eller skapas under entreprenad, projekt eller uppdrag skall

hanteras och skyddas i enlighet med beställarens regler och eventuella ytterliggare krav som finns i

det fall arbetet sker inom ett skyddsobjekt eller med information eller system som omfattas av

säkerhetsskydd.

Det innebär bland annat att entreprenören eller konsulten ska iakttaga stor försiktighet i sin

informationshantering i handelse av att uppdragstagaren far tillgång till kanslig information. Om

atkomsten inte är i paritet med säkerhetsgodkannandet inför uppdraget maste omedelbart

uppdragsgivaren göras uppmärksam pa detta.

Inom många organisationer gäller det att varje medarbetare själva är ansvariga för att

säkerhetsklassa den information som denne nedtecknar elektroniskt eller på papper. För

uppdragstagare gäller att denne radgör med sin uppdragsgivare när det kan befaras att producerad

information behöver sekretessklassas.

Dessa krav kan utformas enligt följande:

Krav 5.1.1

Arbete som innebär tillgång till IT-system och IT-infrastruktur innebär att beställaren

skall godkanna såval personal som skall fa atkomst, samt godkanner de arbetsmoment

som skall utföras.

Krav 5.1.2

Leverantören/implementatören skall tillgodose att det finns rutiner för att hantera

konfidentiell information, att personal är adekvat utbildad och kunnig till relevant

kompetensgrad med avseende IT- och informationssäkerhet.

4.2 IT-säkerhetstester och granskning av leverabler

Som en del av projektöverlämnande genomförs normalt sett olika typer av granskningar och

kontroller av leverabler. Detta dokument fokuserar på säkerhet och därför är det relevant att

beskriva vissa IT-säkerhetstester och säkerhetsrelaterade granskningar.



12/54

Krav 5.2.1

Som del i upphandling, eller i driftsatt system, skall granskningar, tekniska

säkerhetsgenomgångar eller säkerhetsrevisioner tillatas. Det kan vara beställaren, av

beställaren utsett tredje part eller annan myndighet, eller myndigheter som utför

granskning och kontroll.

Krav 5.2.2

Leverantören bör sjalv ha genomfört IT-säkerhetstester av komponenter och hela

systemlösningar

Krav 5.2.3

I de fall som levrantören/implementatören genomfört egna säkerhetstester bör

testresultat kunna redovisas i samband med anbud eller senare i projektcykeln.

Krav 5.2.4

IT-säkerhetstester skall utföras med komponenter, system, applikationer,

parametersattningar och kommunikationsmekanismer som avses anvandas i

malsystemet.

Krav 5.2.5

IT-säkerhetstester skall utföras i ett så tidigt skede som möjligt, så att testresultatet

kan anvandas och eventuella brister kan atgärdas. Testerna bör utföras pa den

utrustning som skall levereras; härdning skall vara utförd, patchning utförd till aktuell

niva, loggning aktiverad, integration och kommunikation uppsatt och aktiverad.

Krav 5.2.6

Säkerhetstester skall genomföras som ett separat moment i samband med

acceptanstestförfarande (FAT/SAT). Traditionell testning av funktioner utför positiva

tester (att en funktion finns, att ett protokoll verifieras följa specifikation, etc.) medan

säkerhetstester ofta fokuserar pa negativa tester (t.ex. att en komponent inte kraschar

om för stora datamängder skickas, att inte ett oförvantat natpaket kan störa ut en

natverkstjanst, att en säkerhetsfunktion kan förbigås).

I övrigt finns det även krav listade som har att göra med överlämnande till linjeorganisation eller

ordinarie driftförarande. Detta finns närmare specificerat i kapitel ”Fel! Hittar inte referenskälla. Fel!

ttar inte referenskälla.” sid Fel! Bokmärket är inte definierat..


13/54

4.3 Hantering av säkerhetspaverkande fel och sårbarheter

Programvara kan alltid ha latenta programfel, så kallade buggar, vilka kan påverka programmets

funktionalitet, stabilitet, prestanda eller säkerhet. Över tid så upptäcker användare, IT-personal och

andra buggar och dessa blir åtgärdade av leverantörer och programutvecklare. Extra viktigt är det att

säkerhetspåverkande fel, i form av buggar som påverkar säkerhetsegenskaper hos programvaran,

åtgärdas så snabbt som möjligt.


Krav 5.3.1

Leverantören/implementatören skall ha rutiner och beredskap för att med kort varsel

kunna meddela beställaren eller beställarens ombud när säkerhetsbrister hittats i

programkomponenter eller konfigurationsuppsattningar som existerar i det som

levererats till beställaren eller beställarens ombud.

Krav 5.3.2

Leverantören/implementatören skall ha en informationsplikt att kontakta beställaren

eller beställarens ombud när leverantören har kannedom om hot, sårbarheter eller

säkerhetsproblem i sina produkter i allmänhet, såval som i beställaren:s anlaggningar i

synnerhet.

Krav 5.3.3

Leverantören/implementatören skall ha rutiner och beredskap för att till beställaren

eller beställarens ombud kunna leverera programuppdateringar, eller temporära

lösningar i form av instruktioner, när säkerhetsbrister hittats i programkomponenter

eller konfigurationsuppsattningar som existerar i det som levererats till beställaren

eller beställarens ombud.

Krav 5.3.4

Leverantören/implementatören skall ha testprocedurer för att kunna kvalitetstesta

egna eller underleverantörers patchar (programfixar), programuppdateringar eller

andringar. Dessa testprocedurer skall också nyttjas för att testa komponenter fran

tredjepartsleverantörer, vars program ingår i leverantörens system.

Krav 5.3.5

Leverantören/implementatören bör ha samarbete, eller förklara sig villig att

samarbeta, med nationella och internationella organisationer för IT-

sårbarhetshanteringar och incidenthantering, exempelvis SITIC, CERT-CC med flera.


14/54

4.4 Legala krav

System, information och komponenter skall uppfylla svenska lagar, författningar och

myndighetsföreskrifter i avseende skydd av system och information behandlat i systemen. Exempel

pa lagar som maste beaktas är

Säkerhetsskyddslagen (1996:627),

Svenska Kraftnäts Föreskrifter om säkerhetsskydd, SvKFS 2013:1,

Svenska Kraftnäts Föreskrifter om elberedskap, SvKFS 2013:2,

30§ i personuppgiftslagen (1998:204),

Lag om skydd av landskapsinformation (1993:1742)


Krav 5.4.1

Leverantör/implementatör och beställare/upphandlare skall ingående göra en juridisk

analys och gå igenom lagar, förordningar och föreskrifter som är applicerbara för

lösningen innan avtal skrivs eller arbete påbörjas.


15/54

5 Arkitektur och principer Princip 1: En grundlaggande skyddsprincip i IT-säkerhetssammanghang är skydd i djupled (eng.

defence in depth).

Denna skyddsprincip innebär att flera samverkande eller kompletterande skydd existerar och därmed

motverkar att fel eller manipulation av enstaka skydd far omfattande konsekvenser. Exempel pa

skydd kan vara natverksskydd (brandvaggar, sakra kommunikationsprotokoll, innehållskontroll, etc.),

operativsystems- och applikationsskydd (behörighetskontroll, loggning av utförd handling, etc.) eller

anvandarskydd (pop-upruta som kraver lösenord för kanslig operation).

Princip 2: Utrustning och lösningar skall ha inbyggd säkerhet, att säkerhet inte är en option som

kan laggas till i efterhand.

Denna skyddsprincip innebär att behörighetskontroll, filskydd, etc., är exempel pa sådana

skyddsfunktioner som maste vara integrerade pa en lag niva (exempevis i sjalva operativsystemet

eller kontrollprogram) för att inte kunna manipuleras.

Princip 3: Utrustningar och lösningar skall vara säkerhetsmässigt härdade.

Att undvika exponering av sårbarheter i mjukvara, oftast genom att inte ha dessa sårbarheter

installerade eller aktiverade, är ett enkelt satt att undvika IT- säkerhetsproblem. Härdning innebär att

Onödig funktionalitet stangs av, tas bort eller undviks att installeras.

Anvandaratkomst (inkl. system-, ”tjanste”- eller applikationsanvandare) och behörigheter satts restriktivt.

Parametersattning och installningar satts för att vara så sakra som möjligt.

Programuppdateringar och systemändringar görs så att kanda säkerhetsproblem atgärdas.

Extra säkerhetsfunktioner installeras.

Princip 4: Skydda information under bearbetning, lagring och under förmedlande

Oavsett i vilket lage som informationshanteringen är bör information hållas skyddad.

Princip 5: komplexitet i lösningen medför ofta sämre möjligheter till bra säkerhet

Efterstrava enkelhet. Ett vanligt förekommande problem med IT-system och IT- säkerhet är

komplexitet. Komplexa lösningar är svara att såval första som att sakra upp.

Princip 6: Undvik standardsatta lösenord och fabriksinställningar som är säkerhetsmässigt dåliga

Inga standardlösenord. System kommer ofta med allmänt valkanda fabriksinstallningar och

leverantörsspecifika standardlösenord eller krypteringsnycklar.

Princip 7: Fristående funktion

Fristaende funktion. Levererad lösning skall kunna ha bibehållen funktionalitet aven vid tillfallen när

supportfunktioner i form av olika nattjanster såsom exempelvis eventuell domännamnshantering

(DNS) inte fungerar.


16/54

Utgå fran att externa/övriga system är osakra. När ett system eller en komponent skall samexistera

med andra komponenter och system, särskilt när dessa är under annan administrativ kontroll, utgå

fran att dessa system är osakra. Vissa systemlösningar leder till att en angripare latt kan hoppa fran

system till system efter att en gång val ha kommit in.

Princip 8: Säkerheten måste finnas med under hela livscykeln

Livscykelfokus med bibehållet ansvar. Säkerhetsfragor existerar under alla faser (analys, design,

implementation, produktion, förvaltning, vidareutveckling, avveckling) för ett system. I samband med

projektering eller upphandling kan överfokusering ske pa att lösa problemen för stunden. Det är

viktigt att de andra faserna av ett systems livscykel också tacks in.

5.1 Lösningens uppfyllnad av säkerhetsprinciper

De säkerhetsprinciper som listas i dokumentet är fundamental för att skapa det grundskydd som

denna kravsamling skall skapa. Det är därför viktigt att dessa säkerhetsprinciper överförs till krav och

att dessa krav i sin tur redovisas som en del i underlaget.


Krav 6.1

Levererad lösning skall uppfylla principer för skydd i djupled.

Krav 6.2

Levererad lösning skall uppfylla principer för inbyggt skydd.

Krav 6.3

Komponenter och system skall vara härdade av leverantören.

Krav 6.4

Lösningen bör vara utformad att skydda information under alla steg i

informationshanteringen. Bestallaren definierar om särskilda krav pa kryptering eller

skydd av information finns.

Krav 6.5

Lösningsdesign bör följa KISS-principen (”Keep it Simple and Stupid”) för att efterstrava

lattförstaelighet och enkelhet, inte komplexitet i lösningen. Enklare lösningar medför

battre verifierbarhet och översiktbarhet, bade ur ett felsökningshanseende såsom ur

säkerhetshanseende.

Krav 6.6


17/54

Fabriksinstallningar och leverantörsspecifika standardlösenord eller krypteringsnycklar

skall ersattas med nyskapade motsvarigheter som uppfyller beställarens krav. Det är

viktigt att detta sker i samband med systemöverlamnande så att frantradande

entreprenörer eller temporärt involverad personal inte langre kanner till gallande

autentiseringsinformation.

Krav 6.7

Levererad lösning skall kunna fungera fristaende med bibehållen funktion.

Krav 6.8

Lösningsdesign skall utformas så att beroenden mot andra system inte innebär att

systemet tappar skydd.

Krav 6.9

Levererad lösning skall ha en säkerhet som bygger pa att alla delar av

systemets/komponentens livscykel tacks in.


18/54

6 Standarder För att underhålla en lösning över tid så finns det flera viktiga aspekter att betrakta, bland annat

Inom elbranschen är det sedan tidigare vedertaget att internationella standarder används för elteknik, så detta bör även användas för IT i anläggningar och i industriella sammanhang.

Det finns stora fördelar om man som kund inte hamnar i inlåsning till en viss leverantör som är den enda som tillhandahåller en viss lösning, dvs företagsspecifika standardarder och lösningar

För lösningar som bygger på standarder så finns det större chans att flera personer känner till lösningsförslag


Krav 7.1

Lösningen bör bygga pa internationella standarder, nationella standarder,

branschstandarder eller de facto standarder vad det gäller säkerhetsteknik,

säkerhetsprotokoll, säkerhetsprodukter och säkerhetsplattformar.

Krav 7.2

Vilka standardarder leverentören tankt att anvanda skall anges i anbudet för

bestallarens stallningstagande.

Krav 7.3

En vedertagen hållning i IT-säkerhetssammanhang är att stangda företagslösningar för

kryptering inte anses som sakra, framst pa grund av att de inte har genomgått den

granskning i akademi, av myndigheter och av anvandare som öppna lösningar har

utsatts för. Lösningen skall inte bygga pa proprietära (leverantörsspecifika eller

stangda) lösningar för kryptering eller kryptoteknologi. (Dvs leverantören far inte

nyttja egenutvecklade kryptoalgoritmer, kryptografiska checksumme-

berakningsalgoritmer, signeringsalgoritmer, etc i säkerhetsfunktioner).

Krav 7.4

Vilka lösningar som bygger på krypteringsteknik, samt vilka standarder dessa bygger på

skall anges i anbud eller underlag.


19/54

7 Programvara Det är viktigt att all programvara som ingår i lösningen hanteras på ett professionellt sätt. Det

inkluderar bland annat att det finns giltiga licenser och att sammanställningar vilka program och

programkomponenter – med därtill hörande licenser – som finns i det levererade systemet.


Krav 8.1

All installerad programvara skall ha giltiga licenser och avtal.

Krav 8.2

Alla programvarulicenser skall sammanstallas och redovisas.

Krav 8.3

Hos utvecklarna av systemet eller lösningen skall det finnas och användas

versionshantering och en förandringsprocess för hantering av mjukvaruförandringar.

Krav 8.4

Källkod för programvara bör finnas tillgänglig för säkerhetsgranskning, om beställaren

så önskar. Detta kan kräva tecknande av extra sekretessavtal och extra kostnader, men

bör finnas som en option.

Krav 8.5

För av leverantören utvecklad programvara bör leverantören kunna acceptera

kallkodsdeposition hos en betrodd tredje part. Normalt sett så gäller särskilda avtal

mellan licenstagare, licensgivare och den betrodda tredje part som håller kallkoden

disponerad till särskilda omstandigheter intraffar som ger licenstagaren tillgång till

kallkoden.


20/54

8 Programmering Dessa krav kan utformas enligt följande:

Krav 9.1

Leverantör av utrustning som innehåller egenutvecklad mjukvara skall innan vunnen

upphandling kunna redovisa att utvecklingsmetoder.

Krav 9.2

Leverantör av utrustning som innehåller mjukvara skall kunna redovisa att dessa stallt

krav pa underleverantörer av mjukvara att dessa har utvecklingsmetoder och

processer för mjukvarudesign innehåller delar som leder till programvara som

understödjer kvalitetsmässigt god IT- och informationssäkerhet samt robusthet.

SDL (Security Development Lifecycle) är ett exempel pa en utvecklingsmetod utvecklad av Microsoft

som nått stor popularitet och stor spridning. Metoder syftar till högre kodkvalitet som i sin tur leder

till färre IT-säkerhetsproblem.) och processer för mjukvarudesign innehåller delar som leder till

programvara som understödjer kvalitetsmässigt god IT- och informationssäkerhet samt robusthet.


21/54

9 Kommunikation I IT-miljöer är kommunikation mellan program, system och komponenter en central tjänst och

funktion. Denna funktion måste hanteras på ett kvalitativt och säkert sätt.

I SvKFS 2013:2 2 § ”beredskapsatgärder” i stycket rörande förebyggande åtgärder så nämns bland

annat brandväggar, kryptering, virusskydd och avbrottsfri kraft exlicit som en förebyggande åtgärd

för att förstärka IT-säkerheten för styr- och reglersystemets kritiska IT-processer. Alla dessa

säkerhetsåtgärder har bäring på de krav som man ställas på kommunikation,

kommunikationsutrustning samt infrastrukturlösningar i stort.

Hantering av säkerhet på nätverksnivå och i själva kommunikationssystemen, samt tillhörande

rekommendationer för placering och nyttjande, finns beskrivna i kapitel 5.3 (sidorna 38-50) i SvK:s

vägledning för IT-säkerhetsarkitektur.

9.1 Kommunikationsinfrastruktur

En standardsäkerhetsfunktion som finns i kommunikationsinfrastruktur är brandväggar. Med hjälp av

brandväggen kan nätverkstrafik filtreras utifrån trafikinformation, innehåll eller bägge.


Krav 10.1.1

Nätverkstrafik och överförd data bör gå att kontrollera och begränsa, så att

trafikriktningar, sessionsinitiering, anslutning mot vissa tjänster med mera går att

begränsa på nätverksnivå.

Krav 10.1.2

Nätverks- och kommunikationsinfrastrukturen bör kunna indelas i mindre segment,

eller nätverkszoner, vilket skapar ett sätt att isolera IT-resurser i form av servrar och

system från varandra.

Krav 10.1.3

Zonindelning och isolation bör kunna ske med hjälp av brandväggsteknologi eller

liknande.

Krav 10.1.4

Separation mellan olika nät och trafiktyper bör gå att genomföra med logisk (VLAN,

VPN eller liknande) eller fysisk separation (separata kablar) av nätverkstrafiken.

Det skall finnas en strukturerad uppdelning och separation mellan de olika delarna av systemet:

operatörskonsoler, serverdelar, protokollkonverterare/ kommunikationsutrustning, RTU, PLC, etc.


22/54

Otillbörlig atkomst till delar av kommunikationsinfrastrukturen skall inte leda till atkomst till andra

delar av infrastrukturen.

I de fall da det finns säkerhetssystem installerade i natverket, exempelvis brandväggar eller

utrustning för intrångsprevention/intrångsdetektering, så skall natverksarkitekturen under

normaldrift vara sådan att dessa inte är kortslutna eller oanvanda genom att andra

natverkskopplingar förbikopplar säkerhetssystemen.

9.2 WAN-kommunikation och kommunikation via publika/semipublika transmissionsnat

Förutom skydd på en allmän kommunikationsnivå med hjälp av brandväggar, så kan det finnas behov

att skydda överfört information, data eller sessionsinformation på olika sätt på regionala eller publika

nätverk.


Krav 10.2.1

Det bör finnas någon typ av skydd pa kommunikationsniva.

Krav 10.2.2

Kommunicerande noder bör autentisera sig mot varandra (S.k. ömsesidig autentisering

) så att mottagande enhet enbart tillater behörig trafik samt att uppkopplande enhet

vet att den nått ratt enhet.

Krav 10.2.3

Natverkstrafik bör förandringsskyddas så att dataintegriteten bestar.

Krav 10.2.4

Natverkstrafik bör för vissa typer av information kunna skyddas med hjalp av

insynsskydd/sekretess.

9.3 LAN-kommunikation

Förutom skydd på en allmän kommunikationsnivå med hjälp av brandväggar, så kan det finnas behov

att skydda överfört information, data eller sessionsinformation på olika sätt på lokala nätverk.


Krav 10.3.1

Det bör finnas någon typ av skydd pa kommunikationsniva.

Krav 10.3.2


23/54

Kommunicerande noder bör autentisera sig mot varandra så att mottagande enhet

enbart tillater behörig trafik samt att uppkopplande enhet vet att den nått ratt enhet.

Krav 10.3.3

Natverkstrafik bör förandringsskyddas så att dataintegriteten bestar.

Krav 10.3.4

Natverkstrafik skall för viss typ av information (tex inloggningsuppgifter) kunna

skyddas med hjalp av insynsskydd/sekretess.

Krav 10.3.5

När nätverk skall installeras ute i en anläggning så bör minst ett specifikt LAN vara

dedikerat för stationsbuss.

Krav 10.3.6

Atkomst till kommunikationsutrustning och natverksportar eller liknande kan leda till

obehörig atkomst lokalt (stations-LAN) så val som mer geografiskt utspridd. Därför

skall atkomst till kommunikationsutrustning och natverksanslutningar skyddas.

Krav 10.3.7

Tradlös teknik för LAN-kommunikation bör undvikas i anlaggnings-IT-miljö. Om tradlös

kommunikation anvands skall den sakras upp mot avlyssning, förandring och obehörig

atkomst av natinfrastruktur och anslutna system.

9.4 Integration och informationsutbyte


Krav 10.4.1

Särskild säkerhetsutredning skall utföras i samband med att anlaggningssystem skall

integreras mot administrativa system. Utredningen skall bland annat undersöka hur

informationsutbyte sker, vilka risker det finns med sammankopplingen, vilka

säkerhetslösningar som paverkas, vilka nya skydds och säkerhetslösningar som kan

behöva införskaffas eller aktiveras.

Krav 10.4.2

Undersökningen skall dokumenteras och kunna redovisas.


24/54

9.5 Fjärratkomst

En central funktionalitet som finns I många OT- eller SCADA/ICS-miljöer är behovet för fjärråtkomst.

Det kan vara leverantören som behöver göra service. Det kan vara egen jourpersonal som senare

skall kunna jobba hemifrån, etc. Det är viktigt att en fjärråtkomstlösning utformas med säkerhet i

åtanke.

Hantering av säkerhet i fjärråtkomst, samt tillhörande rekommendationer för placering och

nyttjande, finns beskrivna i kapitel 5.3.3 (sidorna 51-52) samt sid 81 och framåt i SvK:s vägledning för

IT-säkerhetsarkitektur.


Krav 10.5.1

Dellösningar eller funktionalitet för fjärråtkomst som ingår i den

levererade/implementerade lösningen skall skyddas mot obehörig användning.

Krav 10.5.2

Om dellösningar eller funktionalitet för fjärråtkomst ingår i den

levererade/implementerade lösningen och dessa används över Internet eller från

andra publika nätverk, så skall överföringen skyddas mot obehörig insyn och

förändring

Krav 10.5.3

Skyddet för fjärråtkomstlösningen skall vara restriktiv och enbart ge begränsad

åtkomst till de system som den behörige explicit tilldelats atkomst till. Det vill säga, väl

ansluten till fjärranslutningen skall det inte ges obegränsad åtkomst till interna system.

Krav 10.5.4

Fjärratkomst skall kunna styras för enskilda användare, för specifika atkomstmönster

(mellan vilka tider atkomst far ske, hur lang tid uppkoppling far ske, etc.)

Krav 10.5.5

Fjärråtkomstlösningen bör ha stöd för förstärkt autentisering, för att komplettera

eventuella traditionella lösenordslösningar.

Krav 10.5.6

Fjärratkomst skall kunna styras för enskilda användare, för specifika atkomstmönster

(mellan vilka tider atkomst far ske, hur lang tid uppkoppling far ske, etc.)

Krav 10.5.7


25/54

Leverantörer/implementatörer som behöver fjärråtkomst för att ha underhåll, service

eller av annan anledning behöver fjärråtkomst, bör kunna använda den fjärråtkomst

som beställaren tillhandahåller.

Krav 10.5.8

All fjärratkomst skall generera spardata över vem, när, hur (vilka

kommunikationssatt/protokoll) och vad som nyttjades i fjärratkomstlösningen.


26/54

10 Datalagring För mycket av den specialutrustning som används inom OT eller SCADA/ICS så kan det vara speciella

lagringslösningar i form av flash-ram eller liknande minneskort som används, snarare än ordinarie

hårddiskar eller SSD-minnen. Ofta är filsystem speciella och möjligheten att arbeta mot dessa diskar

små eller obefintliga. Men för annan utrustning och för andra läsningar så bör de allmänna kraven

vad gäller hantering av lagrad information fortfarande gälla.


Krav 11.1

För informationsbärande enheter, enheter som kan parametersattas eller skraddarsys,

skall det gå att göra säkerhetskopiering av information som finns i enheten. Detta

inkluderar parametrar, skapad information, programkod och annat som är relevant för

att kunna aterskapa ett system.

Krav 11.2

För informationsbärande enheter så skall det gå att aterlasa och aterskapa systemet

utifran den säkerhetskopia av information som skapats.

Krav 11.3

I samband med att utrustning kasseras, utrangeras, lagerställs eller på annat sätt inte

längre drifthålls så bör det gå att tömma den datalagringsmedia som används.


27/54

11 Behorighetssystem och behorighetshantering Behörighetssystem och behörighetshantering är två centrala begrepp för att skapa ett bra

grundskydd i en IT/OT-lösning


Krav 12.1

Atkomst till system och komponenter skall skyddas med behörighetskontroll.

Krav 12.2

Behörighetssystemet skall vara aktiverat och skydda mot obehörig atkomst (lasning),

obehörig förandring (skrivning), manipulation, obehörig installation av nya program.

Krav 12.3

Personer, komponenter, funktioner och tjanster bör ha unika identiteter så att

behörigheter går att anpassa och spardata blir unikt. Att inte uppfylla detta

baskriterium leder till att sparbarhet och oavvislighet inte uppnås.

Krav 12.4

Lagsta möjliga behörigheter bör nyttjas av anvandare, komponenter, programvaror,

tjanster för att inte onödiga rattigheter skall vara utdelade eller nyttjade.

Krav 12.5

Det skall gå att andra behörighetsinformation (lösenord) i system och komponenter.

Det bör gå att centralisera anvandar- och behörighetsinformation.

Krav 12.6

Leverantören skall kunna redovisa om det finns statiska lösenord sparade i filer,

programkod, skript, i hårdvara eller liknande.


28/54

12 Spårbarhet

12.1 Spårdata

Spårdata och spårbarhet innebär en identifikationsmöjlighet av användare, händelser, aktiviteter på

ett entydigt sätt efter det en händelse eller aktivitet har inträffat. Detta är en grundläggande

säkerhetfunktionalitet som behövs i en lösning.


Krav 13.1

Installerade enheter bör kunna lämna spårdata i form av loggar.

Krav 13.2

Generad spårdata skall vara användbar för IT-incidentutredningar.

Krav 13.3

Installerade enheter bör ha stöd för att kunna integreras mot eventuella

logghanterings- och logguppsamlingssystem hos beställaren. Detta kan vara ett

överordnat centralt system för logginsamling eller logghantering.

Krav 13.4

Genererad spardata skall skyddas mot obehörig atkomst, atkomst för insyn likval som

manipulation.

För mer information om IT-incidenthantering, se kapitel ”13.6 Incidenthantering” sid 34.

12.2 Tid och tidshantering

Fungerande och korrekt tidshantering är en central säkerhetsfunktion.


Krav 13.2.1

Det bör gå att stalla klockan pa utrustningen, så att det går att skapa en gemensam

tidsuppfattning mellan installerade eller anslutna system.

Krav 13.2.1

Det bör vara en gemensam tidsuppfattning för alla installerade eller anslutna system.


29/54

För mer information om spårbarhet, se kapitel ”12.1 Spårdata” sid 28.


30/54

13 Specifika säkerhetsfunktioner Detta kapitel går mer I detalj ner och beskriver vissa tekniska eller andra säkerhets- och

skyddsfunktioner som bör kravställas mer ingående.

13.1 Skydd mot skadlig kod

Ett standardproblem i IT-sammanhang är avsiktligt skadlig kod, exempelvis virus, maskar, trojaner,

kan skada ett system, sla ut en funktion eller förbruka resurser såsom kommunikationskapacitet.

I SvKFS 2013:2 2 § ”beredskapsatgärder” i stycket rörande förebyggande åtgärder så nämns

virusskydd exlicit som en förebyggande åtgärd för att förstärka IT-säkerheten för styr- och

reglersystemets kritiska IT-processer.

Skydd mot skadlig kod, samt tillhörande rekommendationer för placering och nyttjande, finns

beskrivna på sidorna 64-65 i SvK:s vägledning för IT-säkerhetsarkitektur.

Förslag till kravställning på skydd mot skadlig kod vid upphandling eller införande är som följer:

Krav 14.1.1

Skydd mot skadlig kod skall finnas i IT-lösningen som nyttjas för anlaggnings-IT.

Krav 14.1.2

Skydd mot skadlig kod skall finnas i test/verifikations- och utvecklingssystem som

används i samband anläggnings-IT-lösningen.

Krav 14.1.3

Skydd mot avsiktligt skadlig kod skall finnas på den datorutrustning som används av

servicetekniker, fältpersonal och andra personer som legitimt har möjlighet att ansluta

utrustning mot anläggnings-IT-systemen.

Krav 14.1.4

Skyddet mot skadlig kod skall kunna uppdateras och vara uppdaterat så att aktuella

signaturfiler, scanningsprogram och liknande är installerade och hålls uppdaterade så

att ett fungerande skydd över tid erhålls.

Krav 14.1.5

Skyddet mot aktivt skadlig kod skall kunna markera genom larm, logg eller annan

åtgärd att skadlig kod, eller effekter därav, har påträffats.

Antivirusprogram är ibland inte möjliga att anvanda i anlaggnings-IT. Det kan vara ett inbyggt system,

de finnas prestandaskal, det kan vara oförenliga krav pa omvärldskoppling för t.ex. uppdatering av


31/54

signaturfiler eller scanningsmotor, det kan vara att det inte finns produkter för den specifika

komponenten eller den aktuella lösningen.

I de fall då traditionella skydd mot avsiktligt skadlig kod inte går att använda så kan alternativa

lösningar där tekniska skydd uppförs på en annan plats än den först tänkta, eller att andra

skyddsmekanismer används.

Förslag till kravställning på alternativa skydd mot skadlig följer:

Krav 14.1.6

Alternativa lösningar och tekniska skydd skall finnas och användas då traditionella

lösningar för att skydda systemet mot införsel och exekvering av okänd kod inte kan,

eller inte önskas, användas.

Krav 14.1.7

Alternativa lösningar och tekniska skydd som används skall kunna aktivt förvaltas och

underhållas över tid.

Alternativa lösningar kan vara lösningar där enbart pa förhand godkända program tillåts laddas och

exekveras, s.k. white listing, kompletterande skydd i form av rutiner och tekniska lösningar för

säkerhetskontroller i samband med in- och utförsel av data via USB-stickor eller via nätverk, etc.

Dessa alternativa skydd kan i underlaget behöva specificeras eller kravställas i mer detalj.

13.2 Intrangsdetektering

Intrångsdetektering är namnet på en funktion för automatiserad detektering av intrangsförsök och

intrang. Dessa säkerhetskomponenter, samt tillhörande rekommendationer för placering och

nyttjande, finns beskrivna på sidorna 43-45 i SvK:s vägledning för IT-säkerhetsarkitektur.


Krav 14.2.1

Lösningen bör ha stöd för nätverksbaserad intrångsdetektering.

Krav 14.2.2

Lösningen bör ha stöd för datorbaserad intrångsdetektering.

För leverantörsspecifika kommunikationsprotokoll skall leverantören kunna bista beställaren med

kunskap om kommunikationsprotokollet så att beställaren kan anpassa brandvaggar, natbaserade

intrangsdetekteringsystem och liknande så att de kan tolka och fungera med dessa protokoll.


32/54

13.3 Övervakning

Exempel på övervakning kan vara:

Säkerhetsövervakning

Övervakning av systemet, applikationerna, lösningens eller enskilda komponenters tillgänglighet, prestanda, kapacitet eller fel

Övervakning är ett brett område som omfattar många tekniker och sätt att utföra själva

övervakningen. Sättet som övervakning utförs på kan exempelvis vara:

Att utrustning larmar och skickar larm till centrala övervakningssystem i samband med att någon övervakad funktion (t.ex. hur hög systemlasten är, hur mycket ledigt lagringsutrymme som kvarstår) har nått ett tröskelvärde

Att det finns särskilda övervakningsutrustningar som utför inspelning av nätverkstrafik för forensisk analys, felsökning och liknande

Dessa säkerhetskomponenter, samt tillhörande rekommendationer för placering och nyttjande, finns

beskrivna på sidorna 36--38 i SvK:s vägledning för IT-säkerhetsarkitektur.

I de fall då övervakning inte är permanent, kan det vara av särskilt intresse att förbereda i

infrastrukturen (t.ex. via förberedd switchport som är uppsatt på visst sätt, eller via en till nätverket

ansluten nätverkstapp) så att det snabbt och enkelt går att ansluta övervaknings- och

felsökningsutrustning. Detta finns uttryckt bland kraven nedan.


Krav 14.3.1

Lösningen bör stödja att ha enkel driftövervakning.

Krav 14.3.2

Beskriv driftövervakningsfunktionerna som ingår i lösningen.

Krav 14.3.3

Lösningen bör stödja att ha enkel säkehetsövervakning.

Krav 14.3.4

Beskriv säkerhetsövervakningsfunktionerna som ingår i lösningen.

Krav 14.3.5

Lösningen bör stödja att anslutning av övervakningsutrustning kan ske på ett icke-

störande sätt, så att existerande kommunikation och nätverkstrafik inte bryts eller

påverkas.

Krav 14.3.6


33/54

Lösningen bör stödja att anslutning av övervakningsutrustning kan ske på ett sätt som

inte möjliggör att anslutande utrustning kan introducera nätverkstrafik eller verka

störande.

Punkten som avser att kunna ansluta övervakningsutrustning på ett icke-störande sätt avser att i

förberedande syfte ha möjliggjort att exempelvis nätverksanalysatorer,

nätverksinspelningsutrustning, intrångsdetekteringsutrustning eller liknande kan ansluta utan att

nätverkets kommunikationsutrustning eller kablage måste ändras under drift. Ett enkelt sätt att

möjliggöra detta är att på förhand tillhanda hålla s.k. span-portar i växlar.

Den sista punkten i kraven ovan realiseras ofta via någon typ av såkallad nätverkstapp (eng. network

tap), vilket tillåter läs-åtkomst men med spärrad skrivmöjlighet för att förhindra att nätverkstrafik

kan skapas. Detta möjliggör att man får garantier att ansluten utrustning inte kan introducera skadlig

kod, generera störande bakgrundstrafik eller nätverkstrafik som påverkar annan utrustning i

nätverket. En nätverkstapp möjliggör också krav 14.3.2 på en nivå som är ännu bättre än vanliga

span-portar.

13.4 Envägskommunikation Envägskommunikation är att med stark kontroll bestämma att datatrafik skall vara enkelriktad. Vissa

lösningar har högre krav på säkerhet, exempelvis genom att man har behov av att styra

informationsflöden bättre eller ha garantier för att data enbart kan skickas åt ett visst håll. Det kan

vara lösningar där man skall skicka ut loggar från ett isolerad och känsligt driftnät. Eller att man vill

kunna ta in tidssynkronisering eller uppdateringar på ett mycket strikt och kontrollerat sätt.


Krav 14.4.1

Om det finns behov av höga krav på nätverkssäkerhet och informationsflödeskontroll

så bör leverantören kunna redovisa hur en lösning för strikt envägskommunikation kan

införas i lösningen.

13.5 Programuppdateringar och programfixar

En central aktivitet för att skapa och sedan bibehålla säkerhet över tid är att se till att den

programvara som används inte innehåller kända, och därmed missbrukbara, säkerhetsbrister.

Förutom härdning, vilket vi beskrivit som en av de grundläggande säkerhetsprinciperna, så är

förvaltning i att kunna uppdatera programvarukomponenter eller ändra konfiguration då

säkerhetsbrister uppdagas en absolut grundläggande säkerhetsaktivitet.


beskrivna på sidan 66 i SvK:s vägledning för IT-säkerhetsarkitektur.


Krav 14.5.1


34/54

Säkerhetsuppdateringar till programvara bör göras tillgänglig utan begränsningar

Krav 14.5.2

Hanteringen av programuppdateringar och programfixar skall skötas rigoröst.

Leverantören/implementatören har att redovisa ett skriftligt underlag för hur de

arbetar enligt de processer eller med de patchhanteringssystem de använder.

Krav 14.5.3

Enbart kanda fixar fran kanda tillverkare skall anvandas, vilket gör att ursprung och

riktighet skall kontrolleras innan uppdateringar och fixar installeras.

Krav 14.5.4

Operativsystem, applikationer eller systemkomponenter skall inte uppdateras

automatiskt. Uppdateringarna maste alltid ske kontrollerat och först efter beslut och

godkannande av beställaren eller beställarombudet.

Krav 14.5.5

Leverantören/implementatören, eller denne utsedd part, som har ansvar för

programvaruunderhåll skall kunna verifiera programändringar i form av

programuppdateringar eller patchar. Kvaliteten hos dessa ändringar skall kontrolleras

så att en programändring inte medför funktionella ändringar eller förändrad

tillgänglighet hos systemet eller lösningen.

Krav 14.5.6

Efter testning av programvaruuppdateringar eller ändringar skall

leverantören/implementatören kunna tillhandahålla dokumentation som visar att

testerna förlöpt utan negativa konsekvenser eller biverkningar.

Krav 14.5.7

För de fall där tillganglighetskrav är höga skall metoder och design för

programuppdateringar och programfixar hantera det faktum att dessa andringar ofta

kraver omstart av enskilda applikationer eller hela system.

13.6 Incidenthantering

Att kunna hantera IT-incidenter (virusangrepp, datorintrång, oförklarliga krashar, etc) som uppstår I

en ICS/SCADA-miljö är viktigt. Inte minst med tanke på att dessa miljöer ofta skiljer sig – både till hur

de underhålls men inte minst vilka tillgänglighetskrav de har på sig – jämfört med vanliga IT-miljöer.

Incidenthantering är en viktig rutin eller process och med därtill hörande arbetsformer, stödverktyg,

med mera.


35/54


Krav 14.6.1

Lösningen bör utformas på ett sådant sätt att det underlättar framtida IT-

incidenthantering i form av skapande av spårdata, möjlighet att inspektera utrustning

för avvikelser i uppsättning mellan förväntad och installerad konfiguration, med mera.

Krav 14.6.2

Arbetet med att hantera incidenter skall ske på ett professionellt sätt.

Krav 14.6.3

Systemleverantörer bör ha kompetens och vilja att kunna bista med fackkunskap om

systemen vid hantering av IT-incidenter som involverar deras system och

komponenter. Detta kan vara en tilläggsfunktion som prissätts separat.

Krav 14.6.4

Leverantören/implementatören bör ha samarbete, eller förklara sig villig att samarbeta

beställarorganisationens egna, eller utpekade tredjepartsaktörer, som arbetar med

säkerhet

13.7 Kontrollutrustning och andutrustning

För ansluten andutrustning eller utrustning för styrning och kontroll, exempelvis RTU (Remote

Terminal Unit), IED (Intelligent Electronic Devices) eller PLC (Programmable Logic Controller) skall

samma regler galla som för annan IT-baserad utrustning. De skall exempelvis härdas, kunna patchas,

inte innehålla standardlösenord, etc. Da denna typ av utrustning i vissa fall anvander anpassade

operativsystem maste omstandigheterna runt dessa utrustningar bedömas var för sig.


Krav 14.7.1

Kontrollutrustning skall i förekommande fall då de ingår i lösningen omfattas av

säkerhetskrav på samma sätt som annan utrustning.

Krav 14.7.2

Kontrollutrustning bör härdas och därmed få mindre aktiv funktionalitet och minskad

exponering.


36/54

Krav 14.7.3

Kontrollutrustning bör konfigureras så att de loggar och larmar till centraliserade IT-

system som kan ta emot loggar från dessa utrustningar.

13.8 Extern IT-utrustning

När utrustning som inte ägs, förvaltas eller kontrolleras av den egna organisationen skall användas

som IT-utrustning i IT-miljön, till exempel för oregelbundna underhållsarbeten utförda av

leverantören, så uppstår situationer där risker kan uppstå.

Extern utrustning är IT-utrustning eller ann digital utrustning som är placerad utanför den egna

kontrollen. Eller som inte tillhör den egna organisationens flotta av utrustning.

Detta krav kan utformas enligt följande:

Krav 14.8.1

För service och underhåll skall enbart en av beställaren för ändamålet tillhandahållen,

eller av beställaren uttryckligen godkand, utrustning anvandas.

13.9 Externa tjänster Externa tjänster är IT-tjänster, nätverkstjänster eller likande som drifthålls av en annan part än den

egna organisationen. Exempel, utifrån detta upphandlande perspektiv, på externa tjänster

inkluderar:

externa webportaler som används för fjärråtkomst för administration av utrustning och funktioner i levererad lösning

molntjänster eller annan XaaS (X as a service) funktionalitet.


beskrivna på sidorna 20-21 samt refereras till på sid 69 i SvK:s vägledning för IT-säkerhetsarkitektur.


Krav 14.9.1

Leverantörer skall kunna redovisa om produkter i lösningen i del eller till fullo består

av, eller har kritiska beroenden av, externa tjänster och funktionalitet.

Krav 14.9.2

I de fall då komponenter som standard har beståndsdelar som i del eller i fullo består

av externa tjänster, eller har kritiska beroenden av externa tjänster, så bör dessa gå att

stängas av eller avinstalleras i den lösning som levereras eller implementeras.

Krav 14.9.3


37/54

Leverantören eller implementatören skall skriftligen kunna redovisa de tekniska

säkerhetsmekanismerna och skyddsfunktioner som ingår i de externa tjänsterna och

funktionerna. Detta bör vara i form av ett redan existerande produkt- och

tjänstebeskrivning (s.k. whitepaper).

Krav 14.9.4

Leverantören eller implementatören skall skriftligen kunna redovisa var och hur

information, främst personuppgifter eller uppgifter som rör elsystemet eller

anläggningsinformation och därmed kan omfattas av säkerhetsskydd, så att beställare

kan ha detta som underlag för sitt interna säkerhetsarbete.

13.10 Fysiskt skydd

Fysiskt skydd av utrustning och lösningar kan vara ett viktig egenskap.


refererad till på sidan 66 i SvK:s vägledning för IT-säkerhetsarkitektur.


Krav 14.10.1

Det skall finnas en genomtankt och avvagd balans mellan fysiskt och logiskt

säkerhet/skydd.

Krav 14.10.2

Genom kommunikationsgranssnitt så sker datautbyte eller styrning av spridda enheter

inom anlaggningen. Utstrackningen av det elektroniska skalskyddet (eng. electronic

perimeter) bör befinna sig innanför fysiskt omradesskydd eller fysiskt skalskydd.

Förutom klassiska krav på områdesskydd och skalskydd så kan det behövas ställas mer IT-relaterade

krav på fysisk säkerhet.


Krav 14.10.3

Inga allmänt tillgangliga natverksportar far finns. Tradlös trafik kan vara atkomlig

utanför skal- och omradesskydd och skall därför skyddas.

Krav 14.10.4


38/54

Utrustning som finns allmänt tillganglig, skall skyddas mot missbruk av utrustningen

sjalvt eller att anslutningar som finns till utrustningen. Det skall t.ex. inte gå att koppla

ur utrustningen och ansluta en egen utrustning och därmed komma at beställarens

natverksinfrastruktur och därtill anslutna annan utrustning.


39/54

14 Dokumentation Dokumentation skall klassas och hanteras i enlighet med regler rörande informationshantering.

Leverantören skall kunna dokumentera

utförda säkerhetsförbattringar,

härdning,

andrade säkerhetspaverkande installningar,

saker som påverkar den löpande förvaltningen och underhållet av system, delsystem och applikationer


Krav 15.1

Leverantören skall i dokumentationsform redovisa säkerhetsarkitekturen för IT-

delarna och IT-komponenter i anlaggningen.

Krav 15.2

Leverantören skall kunna dokumentera och redovisa all programvara och

programvarukomponenter i levererat system.

Krav 15.3

Redovisningen av programvara skall innehålla bl.a. program/modulnamn, version samt

licensformer. Redovisningen bör innehålla bl.a. checksummor av program och

konfigurationsfiler. Detta är särskilt viktigt da vissa program kan omfattas av licenskrav

som maste beaktas och hanteras av beställaren eller beställarombudet.

Krav 15.4

Det bör finnas dokumentation för kommunikation som beskriver informationsflöden,

kommunikationssätt (protokoll), kommunikationsmetoder (logiska portar,

applikationsprotokoll).

Krav 15.5

Det bör finnas dokumentation som beskriver olika exekverande programs

processprioritet, processprivelegiebehov och system/processresursbehov.

Notera att dokumentation som lösenord, krypteringsnycklar, säkerhetskritiska

konfigurationsparametrar maste hanteras med särskild eftertanke. Traditionellt så har

driftsdokumentation med lösenord, etc, förvarats i närheten av IT-systemen i exempelvis


40/54

obemannade anlaggningar. Obehöriga kan därför latt komma över skyddsvärd information vid

exempelvis ett inbrott.


Krav 15.6

Dokumentation som innehåller särskilt säkerhetskänslig information, såsom lösenord

och krypteringsnycklar eller information om uppsättningar av skyddsfunktioner skall

hanteras, levereras och underhållas enligt särskilda rutiner för säkerhetskänslig

information.


41/54

15 Utbildning Kompetensöverföring i form av utbildning är en viktig del vid alla upphandlingar och all projekt som

inför ny utrustning eller ny funktionalitet. Förutom användarutbildning och utbildning rörande drift

av system, komponenter och lösningen kan det finnas behov av särskild utbildning inom säkerhet.

Utbildningen kan behöva omfatta sådan handhavande, systemadministration, löpande förvaltning,

med mera.


Krav 16.1

I de fall lösningen eller leverabler innehåller säkerhetsfunktioner eller

säkerhetspåverkande funktionalitet skall leverantören tillhandahålla utbildning för

beställaren eller beställarens ombud och där ge särskild information om

säkerhetsfunktionerna.


42/54

16 Revision Leverantören skall acceptera att ta emot en IT- och informationssäkerhetsrevision fran beställaren.

Säkerhetsrevisionens uppgift är att kontrollera att leverantören följer dessa riktlinjer samt att den

information som beställaren tillhandahållit skyddas pa ett adekvat satt.


Krav 17.1

Leverantören skall acceptera att beställaren, eller av beställaren utpekad tredje part,

utför IT- och informationssäkerhetsrevision mot levererat system. Revisionens uppgift

är att kontrollera att system, komponenter eller infrastruktur uppfyller de i detta

dokument ställda säkerhetskraven, beställarens säkerhetspolicy, myndighetskrav eller

branschkrav.


43/54

17 Ordlista Följande är centrala begrepp som förekommer i dokumentet:

Anläggning En fast byggnadskonstruktion på land eller vatten. I anläggning inkluderas bl.a. infrastruktur för styrnings- och övervakningssystem och talkommunikationer.

Antagonist motståndare. Ofta i bemärkelsen att det finns personer inblandade som styr och kontrollerar händelser och händelsekedjor

Antagonistisk attack Ett angrepp i vilken en motståndare i form av en eller flera personer medverkar.

Användare Person som nyttjar en informationstillgång, exempelvis en dator eller ett program.

Autentisering. (eng. authentication). Verifiering av uppgiven identitet eller av ett meddelandes riktighet. Metod för att knyta en identitet till ett subjekt.

Auktorisation (eng. authorisation). Princip att tilldela eller faststalla rattigheter hos ett subjekt för atkomst till objekt. Kallas aven behörighetshantering.

Avsiktligt skadlig kod (eng. malicious code, hostile code eller malware) ar en fackterm och ett samlingsnamn pa en mangd sakerhetsproblem som ar förknippade med program som bestar av, eller innehåller, avsiktligt skadliga program- och programdelar.

Behörighet Användarrättighet att nyttja informationstillgång på specificerat sätt

Brandvägg (eng. firewall). En eller flera natverkskomponenter vars regelverk kontrollerar, begransar eller övervakar trafikutbyte mellan tva, eller fler, natverk.

Datadiod (eng. data diode) Teknisk säkerhetslösning för att kunna skapa garanterad trafikriktningshantering, så att nätverkstrafik enbart kan skickas åt ett visst kontrollerat håll. Se vidare envägskommunikation.

Dataintegritet (eng. data integrity). Försakran, ofta med hjalp av tekniska skydd, att data ar komplett och korrekt.

Driftcentral Fast eller rörlig central för drift- och övervakning av produktionsanläggningar, stationer och/eller elnät

Elberedskap planering, ledning och samordning elförsörjningens resurser för att undvika elbrist samt tillgodose samhällets behov av el i olika sammanhang inklusive i kris och krig.

Envägskommunikation. Form av kommunikation som är enkelriktad. I dator- och informationssäkerhetssammanhang är detta en egenskap som ibland är önskvärd då informationsflöden behöver kontrolleras. Det kan vara så att ett i övrigt isolerat nätverk behöver skicka ut loggar, men samtidigt när detta nät kopplas mot omvärlden vill man få någon typ av garanti att det inte finns några möjligheter att föra in data- eller program via


44/54

denna anslutning. Då kan en envägskommunikation som skapar enkelriktad trafik vara en lämplig lösning.

Fjärråtkomst Anslutning på distans, ofta via kopplande datanätverk, där användaren från en eller flera datorer kan nå andra anslutna datorer. Används ofta för support, diagnostik och underhåll av leverantörer eller personal som har jour.

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.

Hot (eng. threat). Oönskade medvetna eller omedvetna handlingar eller handelser, som utförs eller orsakas av människor, av människan skapade artefakter eller naturliga fenomen och som antas kunna riktas mot viktiga värden eller en aktuell tillgång.En kortare definition kan vara en möjlig, oönskad händelse med negativa konsekvenser för verksamheten

Härdning (eng. hardening) Ett hardat system ar ett system dar funktioner i operativsystem ar anpassade till att stödja systemets primara funktion och administrativa atgarder. Ovriga funktioner ar avslagna, nedlasta och pa annat satt konfigurerade för att förhindra att systemet anvands pa ett oönskat satt. Systemets primara funktion ar aven mycket begransat sa att den primara funktionen endast far genomföra de förandringar som det ar designat för och att dessa kontroller inte framst kontrolleras av programmet, utan av operativsystemet.

IKT Förkortning för informations- och kommunikationsteknik (eng. Information and Communication Technology, ICT). Vanligt förekommande term för de sammansatta IT och kommunikationsområdena.

Incident I dessa sammanhang avser ordet oftast ”IT-incident” da incidenten involverar informationsteknik i någon utformning

Incidenthantering Hanteringen, inklusive utredning, av en IT-incident och de konsekvenser denna incident medfört

Informationssäkerhet (eng. information security). Atgarder för att skydda information mot obehörig förandring, hindra informationslackage, hindra förstörelse av information samt se till att information är tillganglig med ratt kvalitet i ratt tid.

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 intrång.

Intrångsdetekteringssystem Automatiserad detektion och analys av händelser som kan uppfattas som säkerhetsöverträdelser, intrångsförsök eller liknande.

IT Förkortning för Informationsteknologi (eng. Information Technology, IT).. Se IKT

IT-säkerhet (eng. IT security). Skydd av informationstillgångar såsom information, mjuk- och hårdvara.

IT-säkerhetsarkitektur. Den sammanhållna skydds- och säkerhetsmodellen för ett IT-landskap inkluderande system, infrastruktur och mjukvara.


45/54

Logg Insamlad information i syfte att skapa spårbarhet innefattande tidpunkter, händelser, aktiviteter, användare, med mera.

Logiska hot Hot som kan påverka, eller resultera i konsekvenser, saker i den logiska, digitala världen

Logisk säkerhet (eng. logical security) Alla aspekter av säkerhet som är relaterat till elektroniska, digitala objekt.

Logisk bomb Skadlig kod innefattande en dold funktion i ett program eller programsystem som under vissa villkor utlöser en oönskad aktivitet

Mannen-i-mitten-attack . En obehörig tredje part sitter mellan två kommunicerande enheter och fångar upp, och möjligtvis även förändrar, överförd information mellan de två enheterna. Attacken kan exempelvis utföras på ett datornätverk, mellan kortläsare och dator, mellan tangentbord och dator, med mera. Attacken är även kallad janusattack

Kryptering (eng. encryption) är processen för att omvandla klartext till kryptotext.

Kryptosystem (eng. encryption system) är en utrustning eller program som, inklusive nyckelhantering, som anvands för kryptografisk tillampning – omvandling mellan klartext och kryptotext.

Oavvislighet (eng. non-repudiation). Ett specifik atagande eller en utförd handling i efterhand inte skall kunna förnekas av utföraren.

OT. En förkortning för operations technology, vilket i sin tur skall beteckna hård- och mjukvara som styr, kontrollerar eller inhämtar statusinformation från fysiska maskiner. En annan beteckning som ibland används för industriella informations och kontrollsystem som används för automationsfunktionalitet.

Patch. Se programvarufix

Policy övergripande avsikt och viljeinriktning formellt uttryckt av ledningen.

Programvarufix. 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 installera en patch medför att man har en kvarvarande risk då programfelet, exempelvis ett säkerhetsrelaterat programfel, är latent och möjligt att missbruka.

Redundans Egenskap hos ett system eller systemkomponent för att begränsa konsekvenser av uppkomna fel.

Revision Oberoende granskning och uttalande om information eller vissa förhållanden.

Risk- och sårbarhetsanalys (eng. risk assessment). Analys för att hitta vilka hot och risker som finns mot ett viss system eller en viss verksamhet. Ibland aven kallad hot- och riskanalys.


46/54

Sekretess (eng. confidentiality). Att information enbart ar tillganglig och atkomlig för behöriga. Kallas ibland ocksa för konfidentialitet.

Skada fel som uppstått eller orsakats vid ett särskilt tillfälle

Skadekostnad sammanlagt värde av ett angrepps konsekvenser

Skadlig kod Samlingsnamn för virus, maskar, logiska bomber, bakdörrar och annat som skapats med uppsåt att ha en försåtlig funktion

Skydd effekt av handlingar, rutiner och tekniska arrangemang som syftar till att minska sårbarhet

Skydd mot terrorism Begrepp som införs i säkerhetsskyddslagen om att en verksamhet skall ha skydd mot terroristbrott, vilket består i olika former av sabotage, grovt sabotage eller hot om detta. Skyddet mot terrorism innefattar även skydd av IT-system som är centrala eller kritiska komponenter i energisystemet eller som används som centrala eller kritiska delar i fysiska eller logiska säkerhetssystem.

Spårbarhet (eng. accountability). Möjlighet att ifran spardata i efterhand entydigt kunna harleda specifika aktiviteter eller handelser till ett identifierad objekt, oftast en anvandare.

Systemintegritet. (eng. system integrity). Att tillstandet för ett IT-system hålls inom de driftskriterier och tekniska specifikationer som systemet är avsett att operera under. Att dessa förutsattningar bibehalls under tid.

Sårbarhet (eng. vulnerability). svaghet gällande en tillgång eller grupp av tillgångar, vilken kan

utnyttjas av ett eller flera hot

Säkerhetsrevision (eng. security assessment, security audit). Att granska och värdera de säkerhetsfel, sårbarheter i mjukvara och system samt de risker som finns.

Säkerhetstester. (eng. security tests, penetration tests) Att på ett metodisk och systematiskt utföra olika typer av tester som mäter och kontrollerar kvaliteten på säkerhetsrelaterade egenskaper (exempelvis robusthet, att spärra åtkomst för obehöriga, att utföra rätt sorts insynsskydd av överförd information)

Säkerhetsanalys En inventering av skyddsvärda resurser kopplat till hot, risk och sårbarheter. Resultatet skall vara en konkret handlings- och åtgärdsplan

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äkerhetschef En roll i beslutsställning som överser, styr och rådger 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.


47/54

Säkerhetsskyddsförordning Är en förordning kopplad till säkerhetsskyddslag. 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äkerhetsskyddslagen (1996:627)

Säkerhetsskyddschef Utpekad person som utövar kontroll över säkerhetsskyddet. Vid myndigheter skall säkerhetsskyddschefen vara direkt underställd myndighetens chef.

Säkerhetsåtgärd medel för hantering av risk, innefattandes policyer, rutiner, riktlinjer, förfaranden eller organisationsstrukturer vilka kan vara av administrativ, teknisk, ledningsmässig eller juridisk karaktär

TCP/IP Arkitektur för datakommunikation över nätverk med en struktur som delas upp i lager. TCP/IP är ett allmänt förekommande samlingsnamn för en samling protokoll, där varje deltagande dator har en IP-adress.

Tekniskt hot Är av teknisk natur eller som negativt kan påverka teknik, tekniska lösningar och tekniska system.

Tekniska sårbarheter Sårbarheter som har sitt ursprung i tekniska orsaker, ofta IT-tekniska fel, exempelvis programfel, konfigurationsfel i applikationer eller system

Tillgänglighet (eng. availability). Möjligheten att efter behov kunna nyttja IT- och informationstillgangar i förvantad utstrackning samt inom önskad tid.

Tillgänglighetsförlust övergång till ett tillstånd hos ett system där det inte i erforderlig utsträckning eller inom önskad till kan leverera tjänster

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ätverk

Yttre hot . . Hot som har sitt ursprung utanför organisationen

Zonmodell. En zonmodell innebär att man genom att tillämpa olika typer av tekniska skyddsfunktioner (brandväggar, datadioder eller galvanisk separation) separerar, segmenterar eller begränsar datautbytet mellan olika nät/nätsegment i en IT-infrastruktur. Vanligen tillåts en definierad begränsad mängd data i en riktning (från den mer kritiska zonen till en mindre kritiska zon) enligt givna format.


48/54

Överlastningsattack Angrepp med avsikt att slå ut eller allvarligt lasta ned målet (en dator, ett nät, en funktion, mm).

Nomenklaturen anvand för IT i detta dokument ar av naturen vag. Ibland anvands termen SCADA

med den allmänna meningen att det ar anlaggnings-IT eller processkontrollsystem. Ibland används

förkortningen och termen ICS, vilket är en engelsk term för Industrial Control System som har fatt se

en ökande anvandning. Ibland beskriver SCADA, EMS, NMS, etc., specifika system och

systemlösningar.

Da anlaggnings-IT är ett brett begrepp som inkluderar allt mellan enkretsdatorer, inbyggda system

och standard PC:s, så kan riktlinjerna i detta dokument vara svara att applicera fullt ut pa samtliga

delar av anlaggnings-IT. Vissa krav skall ses mot enskilda komponenter, vissa krav skall ses mot

lösningen i sin helhet.


49/54

18 Referenser Nedanstående referenser kan användas för att hitta yterliggare detaljkrav inom olika relevanta

områden såsom juridik, säkerhetsskydd, IT-säkerhet, fysisk säkerhet, ICS/SCADA-säkerhet med mera.

I många fall går materialet att hämta gratis på Internet. I fallen med ISO-standarderna (ISO 27000-

serien) och IEC-standarderna (IEC-62443-serien) är dessa behäftade med relativt stora prislappar.

[1] Svenska Kraftnat, TR2-03 Datorer i kontrollanlaggning

http://www.svk.se/siteassets/aktorsportalen/tekniska-riktlinjer/tr02/1tr02-03-3-d.pdf

[2] Svenska Kraftnat, TR 8-01 Dokumentationskrav

[3] Svenska Kraftnat, TR 9-01 Fysiskt skydd, innehåll

[4] Svenska Kraftnat, TR 9-02 Vagledning fysiskt grundskydd,

[5] Multi-State Information Sharing Analysis Center, Cyber Security Procurement Language for

Control Systems Version. Version 1.8

https://ics-cert.us-

cert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf

[6] Vägledning till ökad säkerhet i industriella informations och styrsystem

https://www.msb.se/RibData/Filer/pdf/27425.pdf

[7] SS-ISO/IEC 27000:2014 Informationsteknik – säkerhetstekniker

– Ledningssystem för informationssäkerhet – Översikt och terminologi


– Ledningssystem för informationssäkerhet - krav


- Riktlinjer för informationssäkerhetsåtgärder

[10] ISO/IEC TR 27019:2013 Information technology -- Security techniques -- Information security

management guidelines based on ISO/IEC 27002 for process control systems specific to the

energy utility industry

[11] SIS HB 550 ”Terminologi för informationssäkerhet”

[12] Stoneburner mfl Engineering principles for Information Technology Security (A Baseline for

Achieving Security) Csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf

[13] Svenska Kraftnäts föreskrifter säkerhetsskydd, SvKFS 2013:1

http://www.svk.se/siteassets/om-oss/foreskrifter/svkfs-2013-1-webb.pdf

[14] Svenska Kraftnäts föreskrifter elberedskap, SvKFS 2013:2

http://www.svk.se/siteassets/om-oss/foreskrifter/svkfs-2013-2.pdf

http://www.svk.se/siteassets/aktorsportalen/tekniska-riktlinjer/tr02/1tr02-03-3-d.pdf

https://ics-cert.us-cert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf

https://ics-cert.us-cert.gov/sites/default/files/documents/Procurement_Language_Rev4_100809.pdf


http://www.svk.se/siteassets/om-oss/foreskrifter/svkfs-2013-1-webb.pdf

http://www.svk.se/siteassets/om-oss/foreskrifter/svkfs-2013-2.pdf


50/54

[15] Svenska Kraftnät ”Hotkatalog för elbranschen”

[16] Vägledning Informations och IT-säkerhet samt säkerhetsskydd

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vaegledning-

informations-och-it-saekerhet-samt-saekerhetsskydd.pdf

[17] Svenska Kraftnät ” IT-SÄKERHETSARKITEKTUR - EN VÄGLEDNING FÖR ELBRANSCHEN MED

TYPEXEMPEL OCH REFERENSLOSNINGAR”

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vagledning-it-

sakerhetsarkitektur-final.pdf

[18] IEC 62443-1-1/TS “Industrial communication networks – Network and system security –

Part 1-1: Terminology, concepts and models” Edition 1.0 2009-07

[19] IEC 62443-2-1 “Industrial communication networks – Network and system security –

Part 2-1: Establishing an industrial automation and control system security program”

Edition 1.0 2010-11

[20] IEC TR 62443-2-3:2015 “Security for industrial automation and control systems

- Part 2-3: Patch management in the IACS environment”

[21] IEC 62443-2-4:2015 “Security for industrial automation and control systems

- Part 2-4: Security program requirements for IACS service providers”

[22] IEC/TR 62443-3-1 “Industrial communication networks – Network and system security –

Part 3 1: Security technologies for industrial automation and control systems”

[23] IEC 62443-3-3 “Industrial communication networks – Network and system security –

Part 3-3: System security requirements and security levels” Edition 1.0 2013-08

[24] ISO/IEC 27033-1:2015 Information technology -- Security techniques

-- Network security -- Part 1: Overview and concepts

[25] ISO/IEC 27033-3:2010 Information technology -- Security techniques

-- Network security -- Part 3: Reference networking scenarios

- Threats, design techniques and control issues

[26] Cybersecurity Procurement Language for Energy Delivery Systems, april 2014

http://energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-

EnergyDeliverySystems_040714_fin.pdf

[27] Vägledning – informationssäkerhet i upphandling. Informationssäkerhet i upphandling av

system, outsourcing och molntjänster. Myndigheten för samhällsskydd och beredskap


[28] NIST SP 800-82 Guide to Industrial Control Systems (ICS) Security Supervisory Control and Data

Acquisition (SCADA) systems, Distributed Control Systems (DCS), and other control system

configurations such as Programmable Logic Controllers (PLC)

http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vaegledning-informations-och-it-saekerhet-samt-saekerhetsskydd.pdf

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vaegledning-informations-och-it-saekerhet-samt-saekerhetsskydd.pdf

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vagledning-it-sakerhetsarkitektur-final.pdf

http://www.svk.se/siteassets/aktorsportalen/sakerhetsskydd/dokument/vagledning-it-sakerhetsarkitektur-final.pdf

http://energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin.pdf

http://energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin.pdf


http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf


51/54


52/54

19 Sakregister

A

Anläggning · 43

Antagonist · 43

Antagonistisk attack · 43

Antivirusprogram · Se skydd mot skadlig kod

Användare · 43

Auktorisation · 43

Autentisering · 43

Avsiktligt skadlig kod · 43

B

Behörighet · 43

Behörighets-

hantering · 27

system · 27

Beredskapsåtgärder · 21

Brandvägg · 22, 43

Bör-krav · 7

C

Centralt system för logginsamling · 28

D

data integrity · 43

Datadiod · 43

Dataintegritet · 43

Dokumentation · 39

Driftcentral · 43

E

Elberedskap · 43

Envägskommunikation · 33, 43

Extern

utrustning · 36

Externa

tjänster · 36

Externa webportaler · 36

F

Felsökning · 32

Fjärråtkomst · 44

Forensisk analys · 32

Fysiska hot · 44

Fysiskt skydd · 37, 44

H

Hot · 44

fysiska · 44

logiska · 45

tekniskt · 47

yttre · 47

Härdning · 44

I

ICS · Se Industrial Control System

IED · Se Intelligent Electronic Devices

IKT · 44

Incident · 44

Incidenthantering · 34, 44

Industrial Control System · 48

Informationssäkerhet · 44

Intelligent Electronic Devices · 35

Intrång · 44

Intrångsdetektering · 22, 31

Intrångsdetekteringssystem · 44

Intrångsprevention · 22

IT · 44

IT-säkerhet · 44

IT-säkerhetsarkitektur · 44

K

Krav

bör · 7

redovisa · 7

skall · 7

skall inte · 7

Kryptering · 45

Kryptosystem · 45


53/54

L

Logg · 45

Logisk bomb · 45

Logisk säkerhet · 45

Logiska hot · 45

M

Mannen-i-mitten-attack · 45

Molntjänster · 36

N

Nätverkstapp · 33

O

Oavvislighet · 45

OT · 45

P

Patch · 45

PLC · Se Programmable Logic Controller

Policy · 45

Programmable Logic Controller · 35

Programvarufix · 45

Programvarukomponenter

uppdatera · 33

R

Redovisa-krav · 7

Redundans · 45

Remote Terminal Unit · 35

Revision · 45

Risk- och sårbarhetsanalys · 45

RTU · Se Remote Terminal Unit

S

SCADA · 48

Sekretess · 46

Sekretess · 46

Skada · 46

Skadlig kod · 46

Skall-krav · 7

Skydd

mot skadlig kod · 30

Skydd · 46

Skydd mot terrorism · 46

Spårbarhet · 46

Spårdata · 28

Svenska Kraftnät · 5

SvK · Se Svenska Kraftnät

Systemintegritet · 46

Sårbarhet · 46

Sårbarheter

tekniska · 47

Säkerhetsanalys · 46

Säkerhetsanalys · 46

Säkerhetschef · 46

Säkerhetshändelse · 46

Säkerhetsrevision · 42, 46

Säkerhetsskyddsansvariga · 6

Säkerhetsskyddschef · 47

Säkerhetsskyddsförordning · 47

Säkerhetsskyddslag · 47

Säkerhetstester · 46

Säkerhetsåtgärd · 47

T

TCP/IP · 47

Teknisk riktlinje · 5

Tekniska sårbarheter · 47

Tekniskt hot · 47

Tidshantering · 28

Tillgänglighet · 47

Tillgänglighetsförlust · 47

TR 04-02 · 5

U

Úppdatera programvarukomponenter · 33

Utbildning · 41

V,W

Virtuellt lokalt nätverk · 47

Virtuellt privat nätverk · 47

VLAN · 47

VPN · 47

X

X as a service · 36


54/54

XaaS · Se X as a service

Y

Yttre hot · 47

Z

Zonmodell · 47

Ö

Överlastningsattack · 48

Övervakning · 32

Documents

Bilaga 1 till Svenska Kraftnäts vägledning om IT ... · 1/54 Bilaga 1 till Svenska Kraftnäts vägledning om IT-säkerhetsarkitektur – Krav på IT-säkerhet vid installation/upphandling/projektering