TEKNISKA RIKTLINJER IT- SÄKERHET

Transkript

1 ENHET, VERKSAMHETSOMRÅDE VÅR BETECKNING I, Informationssystem TR4-02 DATUM SAMRÅD NI, NK, SB TEKNISK RIKTLINJE VERSION B TEKNISKA RIKTLINJER IT- SÄKERHET Introduktion Denna Tekniska Riktlinje gäller för all IT-utrustning som används inom Svenska Kraftnät. För utrustning placerad i transformator- och kopplings-stationer finns kompletterade krav i enlighet med TR2-03. För EMC-krav hänvisas till TR samt för stationsbuss hänvisas till TR SvK405, v2.2, TEKNISKA RIKTLINJER TR4-02 revb 1/18

2 Revision Revision Ändringsnot Datum A Utgiven efter intern remiss B Kommentarer borttagna /18

3 Innehåll 1 Normativa hänvisningar Tekniska riktlinjer Tillämpliga normer och riktlinjer Inledning Definitioner och nomenklatur Undantagshantering Svenska Kraftnäts åtagande Leverantörens åtagande Tillgång till information och IT-infrastruktur IT-säkerhetstester och granskning av leverabler Hantering av säkerhetspåverkande fel och sårbarheter Uppdragets eller leveransens färdigställande Legala krav Arkitektur och principer Standarder Programvara Programmering Kommunikation /18

4 11.1 Kommunikationsinfrastruktur WAN-kommunikation och kommunikation via publika/semipublika transmissionsnät LAN-kommunikation Integration och informationsutbyte Fjärråtkomst Datalagring Behörighetssystem och behörighetshantering Spårbarhet och övervakning Specifika säkerhetsfunktioner Skydd mot skadlig kod Intrångsdetektering Programuppdateringar och programfixar Incidenthantering Kontrollutrustning och ändutrustning Extern IT-utrustning Fysiskt skydd Dokumentation Utbildning Revision Referenser /18

5 1 Normativa hänvisningar Vid utformning av IT-system och digital anläggningsutrustning gäller följande publikationer i senaste utgåva. 1.1 Tekniska riktlinjer TR Systemuppbyggnad TR Datorer i kontrollanläggning TR Stationsbuss TR9-04 Anläggningsskydd TR9-10 Fysisk säkerhet 1.2 Tillämpliga normer och riktlinjer SIS HB550 SIS Handbok 550 Terminologi för informationssäkerhet SS-ISO/IEC 27002:2005 Riktlinjer för styrning av informationssäkerhet 2 Inledning Denna tekniska riktlinje är en sammanställning av krav, regler, principer och rutiner. De har tagits fram för att skydda Svenska Kraftnäts verksamhet och samhällsviktig infrastruktur mot oavsiktliga händelser såväl som avsiktliga angrepp samt säkerställa verksamhetens kontinuitet. Ett grundskydd skapas genom att SvK 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. Anläggningsutrustning i Svenska Kraftnäts ägo består till allt större del på digitalteknik och datorer. Kontrollsystem, och tillhörande datorsystem, nyttjar i större utsträckning allmänna standarder: komponenter, mjukvara och kommunikationsprotokoll. Kundkrav på informationsutbyte med administrativa ITlö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. Anläggnings-IT används 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 också i skyddsutrustning för skydda anläggningar och utrustning på ett säkert sätt. När IT används för skyddsfunktioner är det extra viktigt att IT-säkerheten är god, eller att skyddsfunktionerna hålls logiskt eller fysiskt separerade från andra IT-komponenter. IT i industriella sammanhang innebär ofta särskilda förutsättningar. En viktig aspekt är att system eller komponenter nyttjas under lång tid. Detta påverkar behovet att få in skydd och säkerhetsfrågor i IT-lösningarna rätt ifrå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 5/18

6 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å SvK och dess förvaltarroll, dels på leverantören genom kontraktsåttaganden. De skyddsåtgärder som framgår av denna tekniska riktlinje 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 tekniska riktlinje innehåller enbart vissa delar om skydd för fysiska hot då detta avhandlas i TR9. Vissa fysiska skyddskrav, som skydd mot obehörig anslutning mot kommunikationsnät eller fysiskt skydd mot manipulation och åtkomst av ITutrustning omfattas av denna text. Detta är ett kravställande dokument. Målgruppen är alla som tillhandahåller ITbaserade 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. 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. 3 Definitioner och nomenklatur 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 fastställa rättigheter hos ett subjekt för åtkomst till objekt. Kallas även behörighetshantering. Avsiktligt skadlig kod (eng. malicious code, hostile code eller malware) är en fackterm och ett samlingsnamn på en mängd säkerhetsproblem som är förknippade med program som består av, eller innehåller, avsiktligt skadliga program- och programdelar. Brandvägg (eng. firewall). En eller flera nätverkskomponenter vars regelverk kontrollerar, begränsar eller övervakar trafikutbyte mellan två, eller fler, nätverk. Dataintegritet (eng. data integrity). Försäkran, ofta med hjälp av tekniska skydd, att data är komplett och korrekt. Hot (eng. threat). Oönskade medvetna eller omedvetna handlingar eller händelser, 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. Härdning (eng. hardening) Ett härdat system är ett system där funktioner i operativsystem är anpassade till att stödja systemets primära funktion och administrativa åtgärder. Övriga funktioner är avslagna, nedlåsta och på annat sätt konfigurerade för att förhindra att systemet används på ett oönskat sätt. Systemets primära funktion är även mycket begränsat så att den primära funktionen endast får genomföra de förändringar som det är designat för och att dessa kontroller inte främst kontrolleras av programmet, utan av operativsystemet. Informationssäkerhet (eng. information security). Åtgärder för att skydda information mot obehörig förändring, hindra informationsläckage, hindra 6/18

7 förstörelse av information samt se till att information är tillgänglig med rätt kvalitet i rätt tid. 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. Logisk säkerhet (eng. logical security) Alla aspekter av säkerhet som är relaterat till elektroniska, digitala objekt. 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 används för kryptografisk tillämpning omvandling mellan klartext och kryptotext. Oavvislighet (eng. non-repudiation). Ett specifik åtagande eller en utförd handling i efterhand inte skall kunna förnekas av utföraren. 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 även kallad hot- och riskanalys. Sekretess (eng. confidentiality). Att information enbart är tillgänglig och åtkomlig för behöriga. Kallas ibland också för konfidentialitet. Spårbarhet (eng. accountability). Möjlighet att ifrån spårdata i efterhand entydigt kunna härleda specifika aktiviteter eller händelser till ett identifierad objekt, oftast en användare. Systemintegritet. (eng. system integrity). Att tillståndet för ett IT-system hålls inom de driftskriterier och tekniska specifikationer som systemet är avsett att operera under. Att dessa förutsättningar bibehålls under tid. Sårbarhet (eng. vulnerability). Skillnaden i form av bristande förmåga att motstå hot, mellan önskad säkerhet och verklig säkerhet i ett system vid ett visst givet tillfälle. 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. Tillgänglighet (eng. availability). Möjligheten att efter behov kunna nyttja IT- och informationstillgångar i förväntad utsträckning samt inom önskad tid. Nomenklaturen använd för IT i detta dokument är av naturen vag. Ibland används termen SCADA med den allmänna meningen att det är anläggnings-it eller processkontrollsystem. Ibland beskriver SCADA, EMS, NMS, etc., specifika system och systemlösningar. Då anläggnings-it är ett brett begrepp som inkluderar allt mellan enkretsdatorer, inbyggda system och standard PC:s, så kan riktlinjerna i detta dokument vara svåra att applicera fullt ut på samtliga delar av anläggnings-it. Vissa krav skall ses mot enskilda komponenter, vissa krav skall ses mot lösningen i sin helhet. 7/18

8 4 Undantagshantering För de fall då dessa riktlinjer inte kan följas krävs det särskild hantering: Undantag från regelverket skall för varje enskilt undantag beslutas av ITsäkerhetschef och driftchef i samråd. Beslutet skall föregås av en analys av vilka hot som kvarstår samt vilka risker som SvK löper på grund av undantaget. Undantaget skall nogsamt dokumenteras i relevant framtagen dokumentation (systemdokumentation, etc.) Driftansvariga för system/anläggning eller motsvarande skall informeras om vilka undantag från IT-säkerhetskraven som tagits. 5 Svenska Kraftnäts åtagande Svenska kraftnäts åtagande omfattar att: Kunna bestämma, samt godkänna, eventuella avsteg från tekniska riktlinjer. Tillsammans med leverantör ta fram underlag för att bestämma nivå på skydd. Som ett viktigt moment att förstå 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 tilltänkta upphandlade lösningen och det systemmiljö med vilket denna skall samexistera och samverka. 6 Leverantörens åtagande Som en del av ett åtagande 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. Leverantören skall i sin lösning se till att IT-skydd och IT-säkerhetsfunktioner är en vital del av levererad lösning. 6.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 Svenska Kraftnäts regler. Det innebär bland annat att entreprenören eller konsulten ska iakttaga stor försiktighet i sin informationshantering i händelse av att uppdragstagaren får tillgång till känslig information. Om åtkomsten inte är i paritet med säkerhetsgodkännandet inför uppdraget måste omedelbart uppdragsgivaren göras uppmärksam på detta. Inom Svenska Kraftnät gäller att varje medarbetare själv är ansvarig för att säkerhetsklassa den information som denne nedtecknar elektroniskt eller på papper. För uppdragstagare gäller att denne rådgör med sin uppdragsgivare när det kan befaras att producerad information behöver sekretessklassas. 8/18

9 Arbete som innebär tillgång till IT-system och IT-infrastruktur innebär att Svenska kraftnät skall godkänna såväl personal som skall få åtkomst, samt godkänner de arbetsmoment som skall utföras. Leverantören skall tillgodose att det finns rutiner för att hantera konfidentiell information, att personal är utbildad och kunnig till relevant kompetensgrad med avseende IT- och informationssäkerhet. 6.2 IT-säkerhetstester och granskning av leverabler Som del i upphandling, eller i driftsatt system, skall granskningar, tekniska säkerhetsgenomgångar eller säkerhetsrevisioner tillåtas. Det kan vara SvK, av SvK utsett tredje part eller annan myndighet, eller myndigheter som utför granskning och kontroll. Leverantören bör självt ha genomfört IT-säkerhetstester av komponenter och hela systemlösningar och ha testresultat som kan redovisas i samband med anbud eller senare i projektcykeln. IT-säkerhetstester skall utföras med komponenter, system, applikationer, parametersättningar och kommunikationsmekanismer som avses användas i målsystemet. IT-säkerhetstester skall utföras i ett så tidigt skede som möjligt, så att testresultatet kan användas och eventuella brister kan åtgärdas. Testerna bör utföras på den utrustning som skall levereras; härdning skall vara utförd, patchning utförd till aktuell nivå, loggning aktiverad, integration och kommunikation uppsatt och aktiverad. 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 på negativa tester (t.ex. att en komponent inte kraschar om för stora datamängder skickas, att inte ett oförväntat nätpaket kan störa ut en nätverkstjänst, att en säkerhetsfunktion kan förbigås). 6.3 Hantering av säkerhetspåverkande fel och sårbarheter Leverantören skall ha rutiner och beredskap för att med kort varsel kunna meddela Svenska kraftnät när säkerhetsbrister hittats i programkomponenter eller konfigurationsuppsättningar som existerar i det som levererats till SvK. Leverantören skall ha en informationsplikt att kontakta Svenska Kraftnät när leverantören har kännedom om hot, sårbarheter eller säkerhetsproblem i sina produkter i allmänhet, såväl som i SvK:s anläggningar i synnerhet. Leverantören skall ha rutiner och beredskap för att till Svenska kraftnät kunna leverera programuppdateringar, eller temporära lösningar i form av instruktioner, när säkerhetsbrister hittats i programkomponenter eller konfigurationsuppsättningar som existerar i det som levererats till SvK. Leverantören skall ha testprocedurer för att kunna kvalitetstesta egna eller underleverantörers patchar (programfixar), programuppdateringar eller ändringar. Dessa testprocedurer skall också nyttjas för att testa komponenter från tredjepartsleverantörer, vars program ingår i leverantörens system. 9/18

10 Leverantö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. 6.4 Uppdragets eller leveransens färdigställande Leverantören skall under såväl projektfas som underhållsfas uppfylla de krav som ställs i TR9 gällande hantering av fysiskt tillträde Leverantören skall uppfylla de krav vad det gäller uppdragets avslut som finns i instruktionen Konsultuppdrag vid SvK rutiner och krav, inklusive regler för införsel och utförsel av information, införsel av programvara, uppgraderingar, etc. 6.5 Legala krav System, information och komponenter skall uppfylla svenska lagar, författningar i avseende skydd av system och information behandlat i systemen. Exempel på lagar som måste beaktas är Säkerhetsskyddslagen (1996:627), 30 i personuppgiftslagen (1998:204), Lag om skydd av landskapsinformation (1993:1742) m.fl. Leverantör och upphandlare skall närmare gå igenom lagar som är applicerbara för lösningen innan avtal skrivs eller arbete påbörjas. 7 Arkitektur och principer En grundläggande skyddsprincip i IT-säkerhetssammanghang är skydd i djupled (eng. defence in depth), där flera samverkande eller kompletterande skydd existerar och därmed motverkar att fel eller manipulation av enstaka skydd får omfattande konsekvenser. Exempel på skydd kan vara nätverksskydd (brandväggar, säkra kommunikationsprotokoll, innehållskontroll, etc.), operativsystems- och applikationsskydd (behörighetskontroll, loggning av utförd handling, etc.) eller användarskydd (pop-upruta som kräver lösenord för känslig operation). Levererad lösning skall uppfylla principer för skydd i djupled. En annan skyddsprincip är att utrustning skall ha inbyggd säkerhet, inte att säkerhet är en option som kan läggas till i efterhand. Behörighetskontroll, filskydd, etc., är exempel på sådana skyddsfunktioner som måste vara integrerade på en låg nivå (exempevis i själva operativsystemet eller kontrollprogram) för att inte kunna manipuleras. Levererad lösning skall uppfylla principer för inbyggt skydd. Att undvika exponering av sårbarheter i mjukvara, oftast genom att inte ha dessa sårbarheter installerade eller aktiverade, är ett enkelt sätt att undvika ITsäkerhetsproblem. Härdning innebär att Onödig funktionalitet stängs av, tas bort eller undviks att installeras. Användaråtkomst (inkl. system-, tjänste - eller applikationsanvändare) och behörigheter sätts restriktivt. Parametersättning och inställningar sätts för att vara så säkra som möjligt. Programuppdateringar och systemändringar görs så att kända säkerhetsproblem åtgärdas. Extra säkerhetsfunktioner installeras. 10/18

11 Komponenter och system skall vara härdade av leverantören. Skydda information under bearbetning, lagring och under förmedlan. Oavsett i vilket läge som informationshanteringen är bör information hållas skyddad. Lösningen bör vara utformad att skydda information under alla steg i informationshanteringen. Beställaren definierar om särskilda krav på kryptering eller skydd av information finns. Eftersträva enkelhet. Ett vanligt förekommande problem med IT-system och ITsäkerhet är komplexitet. Komplexa lösningar är svåra att såväl förstå som att säkra upp. Lösningsdesign bör följa KISS-principen ( Keep it Simple and Stupid ) för att eftersträva lättförståelighet och enkelhet, inte komplexitet i lösningen. Enklare lösningar medför bättre verifierbarhet och översiktbarhet, både ur ett felsökningshänseende såsom ur säkerhetshänseende. Inga standardlösenord. System kommer ofta med allmänt välkända fabriksinställningar och leverantörsspecifika standardlösenord eller krypteringsnycklar. Fabriksinställningar och leverantörsspecifika standardlösenord eller krypteringsnycklar skall ersättas med nyskapade motsvarigheter som uppfyller SvK:s krav. Det är viktigt att detta sker i samband med systemöverlämnande så att frånträdande entreprenörer eller temporärt involverad personal inte längre känner till gällande autentiseringsinformation. Fristående funktion. Levererad lösning skall kunna ha bibehållen funktionalitet även vid tillfällen när supportfunktioner i form av olika nättjänster såsom exempelvis eventuell domännamnshantering (DNS) inte fungerar. Levererad lösning skall kunna fungera fristående med bibehållen funktion. Utgå från att externa/övriga system är osäkra. 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å från att dessa system är osäkra. Vissa systemlösningar leder till att en angripare lätt kan hoppa från system till system efter att en gång väl ha kommit in. Lösningsdesign skall utformas så att beroenden mot andra system inte innebär att systemet tappar skydd. Livscykelfokus med bibehållet ansvar. Säkerhetsfrågor 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 på att lösa problemen för stunden. Det är viktigt att de andra faserna av ett systems livscykel också täcks in. Levererad lösning skall ha en säkerhet som bygger på att alla delar av systemets/komponentens livscykel täcks in. 11/18

12 8 Standarder Lösningen skall bygga på internationella standarder, nationella standarder, branschstandarder eller de facto standarder vad det gäller säkerhetsteknik, säkerhetsprotokoll, säkerhetsprodukter och säkerhetsplattformar. Vilken standard leverentören tänkt använda skall anges i anbudet för beställarens ställningstagande. En vedertagen hållning i IT-säkerhetssammanhang är att stängda företagslösningar för kryptering inte anses som säkra, främst på grund av att de inte har genomgått den granskning i akademi, av myndigheter och av användare som öppna lösningar har utsatts för. Lösningen får inte bygga på proprietära (leverantörsspecifika eller stängda) lösningar för kryptering eller kryptoteknologi. (Dvs leverantören får inte nyttja egenutvecklade kryptoalgoritmer, kryptografiska checksummeberäkningsalgoritmer, signeringsalgoritmer, etc i säkerhetsfunktioner). 9 Programvara All installerad programvara skall ha giltiga licenser och avtal. Alla programvarulicenser skall sammanställas och redovisas. Det skall finnas versionshantering och en förändringsprocess för hantering av mjukvaruförändringar. För av leverantören utvecklad programvara skall leverantören kunna acceptera källkodsdeposition hos en betrodd tredje part. Normalt sett så gäller särskilda avtal mellan licenstagare, licensgivare och den betrodda tredje part som håller källkoden disponerad till särskilda omständigheter inträffar som ger licenstagaren tillgång till källkoden. 10 Programmering Leverantör av utrustning som innehåller egenutvecklad mjukvara skall innan vunnen upphandling kunna redovisa att utvecklingsmetoder (SDL (Security Development Lifecycle) är exempel på 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. Leverantör av utrustning som innehåller mjukvara skall kunna redovisa att dessa ställt krav på 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. 11 Kommunikation 11.1 Kommunikationsinfrastruktur Det skall finnas en strukturerad uppdelning och separation mellan de olika delarna av systemet: operatörskonsoler, serverdelar, protokollkonverterare/ kommunikationsutrustning, RTU, PLC, etc. Otillbörlig åtkomst till delar av kommunikationsinfrastrukturen skall inte leda till åtkomst till andra delar av infrastrukturen. 12/18

13 I de fall då det finns säkerhetssystem installerade i nätverket, exempelvis brandväggar eller utrustning för intrångsprevention/intrångsdetektering, så skall nätverksarkitekturen under normaldrift vara sådan att dessa inte är kortslutna eller oanvända genom att andra nätverkskopplingar förbikopplar säkerhetssystemen WAN-kommunikation och kommunikation via publika/semipublika transmissionsnät Det skall finnas någon typ av skydd på kommunikationsnivå. Kommunicerande noder skall autentisera sig mot varandra (S.k. ömsesidig autentisering ) så att mottagande enhet enbart tillåter behörig trafik samt att uppkopplande enhet vet att den nått rätt enhet. Nätverkstrafik bör förändringsskyddas så att dataintegriteten består. Nätverkstrafik skall för vissa typer av information kunna skyddas med hjälp av insynsskydd/sekretess LAN-kommunikation Det bör finnas någon typ av skydd på kommunikationsnivå. Kommunicerande noder bör autentisera sig mot varandra så att mottagande enhet enbart tillåter behörig trafik samt att uppkopplande enhet vet att den nått rätt enhet. Nätverkstrafik bör förändringsskyddas så att dataintegriteten består. Nätverkstrafik skall för viss typ av information (tex inloggningsuppgifter) kunna skyddas med hjälp av insynsskydd/sekretess. Minst ett specifikt LAN skall vara dedikerat för stationsbuss och beskrivs i TR Åtkomst till kommunikationsutrustning och nätverksportar eller liknande kan leda till obehörig åtkomst lokalt (stations-lan) så väl som mer geografiskt utspridd. Därför skall åtkomst till kommunikationsutrustning och nätverksanslutningar skyddas. Trådlös teknik för LAN-kommunikation bör undvikas i anläggnings-it-miljö. Om trådlös kommunikation används skall den säkras upp mot avlyssning, förändring och obehörig åtkomst av nätinfrastruktur och anslutna system Integration och informationsutbyte Särskild säkerhetsutredning skall utföras i samband med att anläggningssystem 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 påverkas, vilka nya skydds och säkerhetslösningar som kan behöva införskaffas eller aktiveras. Undersökningen skall dokumenteras och kunna redovisas Fjärråtkomst Lösningar för fjärråtkomst skall skyddas mot obehörig användning. Skydd på fjärråtkomst skall vara restriktiv och enbart ge begränsad åtkomst till de system som den behörige explicit tilldelats åtkomst till. Fjärråtkomst skall kunna styras för enskilda användare, för specifika åtkomstmönster (mellan vilka tider åtkomst får ske, hur lång tid uppkoppling får ske, etc.) 13/18

14 All fjärråtkomst skall generera spårdata över vem, när, hur (vilka kommunikationssätt/protokoll) och vad som nyttjades i fjärråtkomstlösningen. 12 Datalagring För informationsbärande enheter, enheter som kan parametersättas eller skräddarsys, 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 återskapa ett system. För informationsbärande enheter, skall det gå att återläsa och återskapa systemet utifrån den säkerhetskopia av information som skapats. 13 Behörighetssystem och behörighetshantering Åtkomst till system och komponenter skall skyddas med behörighetskontroll. Behörighetssystemet skall vara aktiverat och skydda mot obehörig åtkomst (läsning), obehörig förändring (skrivning), manipulation, obehörig installation av nya program. Personer, komponenter, funktioner och tjänster bör ha unika identiteter så att behörigheter går att anpassa och spårdata blir unikt. Att inte uppfylla detta baskriterium leder till att spårbarhet och oavvislighet inte uppnås. Lägsta möjliga behörigheter bör nyttjas av användare, komponenter, programvaror, tjänster för att inte onödiga rättigheter skall vara utdelade eller nyttjade. Det skall gå att ändra behörighetsinformation (lösenord) i system och komponenter. Det bör gå att centralisera användar- och behörighetsinformation. Leverantören skall kunna redovisa om det finns statiska lösenord sparade i filer, programkod, skript, i hårdvara eller liknande. 14 Spårbarhet och övervakning Installerade enheter bör kunna lämna spårdata i form av loggar. Generad spårdata skall vara användbar för IT-incidentutredningar. Installerade enheter bör ha stöd för att kunna integreras mot eventuella logghanterings- och logguppsamlingssystem hos Svenska Kraftnät. Detta kan vara ett överordnat centralt system för logghantering. Det bör gå att ställa klockan på utrustningen, så att det går att skapa en gemensam tidsuppfattning mellan installerade eller anslutna system. Det bör vara en gemensam tidsuppfattning för alla installerade eller anslutna system. Genererad spårdata skall skyddas mot obehörig åtkomst, åtkomst för insyn likväl som manipulation. 14/18

15 15 Specifika säkerhetsfunktioner 15.1 Skydd mot skadlig kod Ett standardproblem i IT-sammanhang är avsiktligt skadlig kod, exempelvis virus, maskar, trojaner, kan skada ett system, slå ut en funktion eller förbruka resurser såsom kommunikationskapacitet. Skydd mot skadlig kod skall finnas i IT-lösningen som nyttjas för anläggnings-it. Skydd mot skadlig kod skall finnas i test/verifikations- och utvecklingssystem som används i samband anläggnings-it-lösningen. Skydd mot avsiktligt skadlig kod skall även finnas på den datorutrustning som används av servicetekniker, fältpersonal och andra personer som legitimt skall ansluta utrustning mot anläggnings-it-systemen. Skyddet mot skadlig kod skall vara uppdaterat så att aktuella signaturfiler, scanningsprogram och liknande är installerade. Antivirusprogram är ibland inte möjliga att använda i anläggnings-it. Det kan vara ett inbyggt system, de finnas prestandaskäl, det kan vara oförenliga krav på omvärldskoppling för t.ex. uppdatering av signaturfiler eller scanningsmotor, det kan vara att det inte finns produkter för den specifika komponenten. Alternativa lösningar skall då finnas för att skydda systemet mot exekvering av okänd kod, exempelvis lösningar där enbart på förhand godkända program får laddas och exekveras, s.k. white listing Intrångsdetektering Det bör finnas automatiserad detektering av intrångsförsök och intrång. För leverantörsspecifika kommunikationsprotokoll skall leverantören kunna bistå SvK med kunskap om kommunikationsprotokollet så att SvK kan anpassa brandväggar, nätbaserade intrångsdetekteringsystem och liknande så att de kan tolka och fungera med dessa protokoll Programuppdateringar och programfixar Hanteringen av programuppdateringar och programfixar skall skötas rigoröst. Enbart kända fixar från kända tillverkare skall användas. Ursprung och riktighet skall kontrolleras innan uppdateringar och fixar installeras. Operativsystem, applikationer eller systemkomponenter skall inte uppdateras automatiskt. Uppdateringarna måste alltid ske kontrollerat och först efter beslut och godkännande av SvK. För de fall där tillgänglighetskrav är höga skall metoder och design för programuppdateringar och programfixar hantera det faktum att dessa ändringar ofta kräver omstart av enskilda applikationer eller hela system Incidenthantering Systemleverantörer bör kunna bistå med fackkunskap om systemen vid hantering av IT-incidenter som involverar deras system och komponenter. 15/18

16 15.5 Kontrollutrustning och ändutrustning För ansluten ändutrustning eller utrustning för styrning och kontroll, exempelvis RTU (Remote Terminal Unit), IED (Intelligent Electronic Devices) eller PLC (Programmable Logic Controller) skall samma regler gälla som för annan IT-baserad utrustning. De skall exempelvis härdas, kunna patchas, inte innehålla standardlösenord, etc. Då denna typ av utrustning i vissa fall använder anpassade operativsystem måste omständigheterna runt dessa utrustningar bedömas var för sig Extern IT-utrustning För service och underhåll skall en av SvK tillhandahållen eller av SvK godkänd utrustning användas Fysiskt skydd Det skall finnas en genomtänkt och avvägd balans mellan fysiskt och logiskt säkerhet och skydd. Genom kommunikationsgränssnitt så sker datautbyte eller styrning av spridda enheter inom anläggningen. Utsträckningen av det elektroniska skalskyddet (eng. electronic perimeter) bör befinna sig innanför fysiskt områdesskydd eller fysiskt skalskydd. Inga allmänt tillgängliga nätverksportar får finns. Trådlös trafik kan vara åtkomlig utanför skal- och områdesskydd och måste därför skyddas. Utrustning som finns allmänt tillgänglig, skall skyddas mot missbruk av utrustningen självt 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 åt SvK:s nätverksinfrastruktur och därtill anslutna annan utrustning. 16 Dokumentation Dokumentation skall klassas och hanteras i enlighet med regler rörande informationshantering. Leverantören skall redovisa säkerhetsarkitekturen för anläggningen. Leverantören skall kunna dokumentera utförda säkerhetsförbättringar, härdning, ändrade säkerhetspåverkande inställningar. Leverantören skall kunna dokumentera och redovisa all programvara och programvarukomponenter i levererat system. Redovisningen 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 då vissa program kan omfattas av licenskrav som måste beaktas och hanteras av SvK. Det bör finnas dokumentation för kommunikation som beskriver informationsflöden, kommunikationssätt (protokoll), kommunikationsmetoder (logiska portar, applikationsprotokoll) Det bör finnas dokumentation som beskriver olika körande programs processprioritet, processprivelegiebehov och processresursbehov. Notera att dokumentation som lösenord, krypteringsnycklar, säkerhetskritiska konfigurationsparametrar måste hanteras med särskild eftertanke. Traditionellt så har driftsdokumentation med lösenord, etc, förvarats i närheten av IT-systemen i 16/18

17 exempelvis obemannade anläggningar. Obehöriga kan därför lätt komma över skyddsvärd information vid exempelvis ett inbrott. 17 Utbildning Leverantören skall i sin utbildning för SvK ge särskild information om säkerhetsfunktionerna i systemet i den utbildning som ges. 18 Revision Leverantören skall acceptera att ta emot en IT- och informationssäkerhetsrevision från Svenska Kraftnät. Revisionens uppgift är att kontrollera att leverantören följer dessa riktlinjer samt att den information som SvK tillhandahållit skyddas på ett adekvat sätt. Leverantören skall acceptera att SvK eller tredje part utför IT- och informationssäkerhetsrevision mot levererat system. Revisionens uppgift är att kontrollera att system, komponenter eller infrastruktur uppfyller dessa riktlinjer, myndighetskrav eller branschkrav. 17/18

18 19 Referenser [1] Svenska Kraftnät, TR2-03 Datorer i kontrollanläggning [2] Svenska Kraftnät, TR 8-01 Dokumentationskrav [3] Svenska Kraftnät, TR 9-01 Fysiskt skydd, innehåll [4] Svenska Kraftnät, TR 9-02 Vägledning fysiskt grundskydd, [5] Multi-State Information Sharing Analysis Center, Cyber Security Procurement Language for Control Systems Version. Version 1.8 [6] Krisberedskapsmyndigheten / FIDI-SC Vägledning till ökad säkerhet i digitala kontrollsystem i samhällsviktiga verksamheter. [7] SS-ISO/IEC 27002:2005 Riktlinjer för styrning av informationssäkerhet [8] SIS HB 550 Terminologi för informationssäkerhet [9] Stoneburner mfl Engineering principles for Information Technology Security (A Baseline for Achieving Security) Csrc.nist.gov/publications/nistpubs/800-27/sp pdf [10] Konsultuppdrag vid SvK rutiner och krav 18/18