sou · H9B363 · 2021-07-02 00:00:00 — Det är dock enkelt för en hotaktör att skapa nya versioner av skadlig kod som inte upptäcks av antivirus- programvaran då signaturen inte längre matchar. Antivirusprogram- vara kan därför vara ett svagt skydd mot en kvalificerad aktör, men ska ses som ett grundläggande skydd av informationssystem. Utöver antivirusprogramvaror finns olika säkerhetsprodukter som ytterligare kan stärka skyddet. Initialt bör dock inbyggda funk- tioner användas så långt det är möjligt för att minimera kostnader och komplexitet. Vidare bör rutiner för att kontrollera att skyddet mot skadlig kod är aktivt tas fram och dokumenteras. 7.9.1Allmänt om funktionstester och säkerhetsgranskning Funktionstester och säkerhetsgranskning syftar till att säkerhetsställa att informationssystemet lever upp till den kravställning som ställs på systemet.43 Funktionstester kan säkerställa att systemet är robust och att in- formationen i systemet är tillgänglig och korrekt. 42Effektivt skydd mot skadlig kod kan bestå av: –programexekveringskontroll (så kallad vitlistning) så att enbart godkända program kan exekveras, –behörighetsstyrning (begränsning av administratörsrättigheter), –begränsning av möjlighet att exekvera scriptkod inom olika dokumenttyper såsom exem- pelvis Microsoft Office dokument och PDF-filer, –lokala brandväggar som hindrar skadlig programvara från att sprida sig vidare till andra system, –funktioner som försvårar att exploatera sårbarheter, exempelvis buffertöverskridning, och 433 kap. 1 och 4 §§ säkerhetsskyddsförordningen (2018:658), 2 kap. 17 § och 4 kap. 12–17 §§ Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. granskning utökas detta till att även säkerhetsställa att informations- systemet kan motstå angrepp och andra incidenter som kan utsätta systemet eller informationen för exponering. Dessa tester och gransk- ningar bör genomföras löpande under utvecklingsarbetet för att mini- mera arbetet med rättningar av avvikelser vid driftsättning. I detta avsnitt beskrivs åtgärder som en verksamhetsutövare bör vidta vid funktionstester och säkerhetsgranskning av ett informations- system som har betydelse för säkerhetskänslig verksamhet. Bestämmelser om granskning av informationssystem återfinns bl.a. i Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. Av bestämmelserna i 4 kap. 4 § i PMFS 2019:2 framgår att verksam- hetsutövaren ska se till att egenutvecklad programvara i informations- system som har betydelse för säkerhetskänslig verksamhet granskas för att upptäcka och åtgärda säkerhetsbrister och sårbarheter. Av 5 § följer att verksamhetsutövaren ska se till att tredjeparts- programvara i informationssystem som har betydelse för säkerhets- känslig verksamhet granskas för att upptäcka och åtgärda säkerhets- brister och sårbarheter, eller att programvaran på annat sätt bedöms vara tillförlitlig från säkerhetsskyddssynpunkt. För att säkerställa att programvaran eller systemet fungerar enligt kravställning bör därför tester utföras för att säkerställa att integritet och tillgänglighet kan garanteras. Funktionstester kan bestå av t.ex. belastningstester, redundans- tester och verifiering av indata. Funktionsrelaterade tester av ett in- formationssystem benämns ofta acceptanstest. Acceptanstest innebär att informationssystemet testas mot olika fördefinierade testfall som beskriver en händelse och hur informationssystem ska bete sig vid givna parametrar. Under sådana tester är säkerhetsfunktionerna ofta bara en delmängd av flera funktioner som testas. Säkerhetsgranskning kan bestå av: –granskning av styrning i fråga om rutiner och regelverk, –teknisk granskning som syftar till att verifiera säkerheten i olika tekniska implementationer i ett informationssystem. Vid utveckling av egen programvara bör tekniska säkerhetsgransk- ningar genomföras löpande under utvecklingsprocessen för att enklare kunna upptäcka och åtgärda säkerhetsproblem i ett tidigt skede. Verk- samhetsutövaren kan därför behöva ta fram rutiner och metodstöd för ändamålet så att tekniska säkerhetsgranskningar blir en naturlig del av utvecklingsprocessen. Även om granskning av delkomponenter genomförs under en ut- vecklingsprocess bör en sammantagen säkerhetsgranskning genom- föras, där alla komponenter i informationssystemet testas tillsam- mans. Detta kan lämpligen ske i slutskedet av utvecklingsprocessen, t.ex. genom ett penetrationstest (se nedan). Efter att upptäckta brister och sårbarheter har åtgärdats kan ytter- ligare en granskning behöva ske för att verifiera att dessa i praktiken är åtgärdade, eller på annat sätt motverkats. Säkerhetsgranskningar bör därutöver även genomföras löpande efter att driftsättning har skett. Granskning av programvara från tredje part Vid användning av programvara som inte utvecklats av verksamhets- utövaren (s.k. tredjepartsprogramvara), är det viktigt att verksamhets- utövaren undersöker om denna programvara har oönskad funktiona- litet som negativt kan påverka säkerheten i ett informationssystem där programvaran ska användas. Om det kan antas att tredjeparts- programvara inte granskats av en part som verksamhetsutövaren be- dömer som tillförlitlig, bör verksamhetsutövaren själv genomföra en grundlig säkerhetsgranskning av programvaran innan den implemen- teras i ett informationssystem. Syfte med en sådan grundlig säkerhets- granskning är att upptäcka oönskad funktionalitet samt skydda infor- mationssystemet mot exempelvis dolda kanaler och skadlig kod som kan finnas i tredjepartsprogramvaran. Där det är lämpligt bör även säkerhetskonfigurationen granskas så att produkten implementeras på ett korrekt sätt. En sårbarhetsskanning är en metod som används för att automatiskt kontrollera att säkerhetsuppdateringar är installerade på en it-infra- struktur, system och applikationer. En sårbarhetsskanner kan även hitta enklare brister i konfiguration. En sårbarhetsskanning är ofta ett verktyg som används under ett penetrationstest, men kan även automatiseras för regelbunden kon- troll av applikationer och infrastruktur i it-miljön i syfte att ha kontroll över uppdaterings- och säkerhetsnivån i nätverken. En sårbarhetsskanning kan genomföras både med och utan inloggning i målsystemen.44 Ett penetrationstest är en metod som används för att säkerställa att it- infrastruktur, system och applikationer kan stå emot ett angrepp genom att använda samma metoder som en hotaktör. Penetrationstester kan utföras med olika metodik och det finns ett antal standarder att använda som stöd i testningen samt i bedöm- ningen av brister. Ett penetrationstest kan utföras på allt från en hel it-infrastruktur till enskilda system eller applikationer. Metoderna kan skilja sig mellan olika testscenarier. Det finns i huvudsak tre vanligt 44Flertalet sårbarhetsskannrar erbjuder möjlighet att genomföra aggressiva tester som t.ex. Denial-of-Service-attacker (DoS-attacker). Flertalet sårbarhetsskanners erbjuder även möjlighet att genomföra webbapplikations-skanningar. Det finns också lösningar som enbart genomför skanningar på webbapplikationer. Dessa kan ses som ett komplement till renodlade penetra- tionstester. förekommande koncept för penetrationstester som benämns black- box45, whitebox46 och greybox47. Ett penetrationstest med godkänt resultat kan dock inte ses som en garant för att inte bli utsatt för obehörigt intrång, eftersom det inte finns några garantier att samtliga sårbarheter upptäckts under testet. Ett penetrationstest ger däremot en indikation av hur väl säkerhets- arbetetsarbetet fungerar. De brister som upptäcks vid granskning bör dokumenteras och graderas.48 Graderingen kan sedan ligga till grund för i vilken ord- ning säkerhetsbristerna ska åtgärdas eller på annat sätt motverkas. Efter åtgärdens införande bör ytterligare test ske för att säkerställa att åtgärden har gett avsedd effekt. Rapportering och dokumenta- tion efter ett penetrationstest bör delges berörda inom en organisa- tion så att de får en djupare kunskap om bl.a. upptäckta sårbarheter. 7.10.1Allmänt om åtgärder inför driftsättning Innan ett informationssystem tas i drift behöver verksamhetsutöva- ren säkerställa att informationssystemet är färdigställt och att det kan användas operativt i den säkerhetskänsliga verksamheten. Detta inne- fattar bl.a. att verifiera funktions- och säkerhetskrav, tillse att relevant systemdokumentation är upprättad, genomföra ett eventuellt samråd 45Blackbox är ett koncept där de penetrationstestare som ska utföra testerna inte får någon förhandsinformation om organisationens it-miljö. Även om detta koncept är realistiskt i för- hållande till de förutsättningar en hotaktör har används konceptet väldigt sparsamt. Anledning till detta är att ett penetrationstest enligt konceptet black-box är extremt tidsödande och sällan ger heltäckande resultat då ett penetrationstest vanligtvis genomförs inom en begränsad tids- period. 46Whitebox är ett koncept där de penetrationstestare som ska utföra testerna får fullständig tillgång till information om organisationens it-miljö innan testet påbörjas. Vanligtvis ges pene- trationstestarna även fullständig åtkomst till nätverk, konton, applikationer samt eventuell källkod. Denna metodik är vanligtvis mest effektiv och ger ofta ett heltäckande resultat då tiden kan nyttjas mer effektivt och fler sårbarheter kan upptäckas och graderas. 47Greybox är ett koncept som utgör en kombination av blackbox och whitebox. Här kan in- formationstilldelning och åtkomst anpassas efter behov och förutsättningar. Denna metodik används ofta i övningar med s.k. blue- och red-team mellan säkerhetsövervakning och pene- trationstestare för att testa upptäckandeförmågan och rutiner för incidenthantering inom organisationen. 48Gradering av säkerhetsbrister kan ske med hjälp av t.ex. (). CVSS beaktar olika aspekter av en sårbarhet som t.ex. attackvektor, komplexitet och påverkan på konfidentialitet, riktighet och tillgänglighet. Baserat på dessa parametrar räknas ett värde från 0 till 10 fram, där 0 innebär låg risk för informationssystemet och 10 innebär kritisk risk. med Säkerhetspolisen samt fatta beslut om driftgodkännande.49 Drift- sättning är det sista steget i en utvecklingsprocess innan ett informa- tionssystem kan börja användas operativt av verksamhetsutövaren. Bestämmelser om driftsättning finns bl.a. i Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. Av bestämmelserna i 4 kap. 7 § i PMFS 2019:2 framgår att verksamhetsutövaren ska, innan ett informationssystem som har betydelse för säkerhetskäns- lig verksamhet tas i drift, genomföra tester av säkerhetsskyddsåtgär- derna. Resultatet ska dokumenteras och jämföras med de säkerhets- krav som gäller för informationssystemet. Den särskilda säkerhets- skyddsbedömningen ska uppdateras med eventuella avvikelser och de kompensatoriska åtgärder som måste vidtas. Av bestämmelserna i 4 kap. 9 § i PMFS 2019:2 framgår att verk- samhetsutövaren ska, innan samråd enligt 3 kap. 2 § säkerhetsskydds- förordningen (2018:658) sker med Säkerhetspolisen, kontrollera och dokumentera att de säkerhetskrav som identifierats i den särskilda säkerhetsskyddsbedömningen har implementerats och att säkerhets- skyddsåtgärderna ger avsedd effekt. Av bestämmelserna i 4 kap. 25 § i PMFS 2019:2 framgår att verk- samhetsutövaren även ska ha dokumentation som visar logiska sam- band och inbördes beroenden mellan komponenter som används i informationssystem som har betydelse för säkerhetskänslig verksamhet. Av 26 § följer att verksamhetsutövaren ska för informations- system som är avsett för att behandla säkerhetsskyddsklassificerade uppgifter i säkerhetsskyddsklassen kvalificerat hemlig, dokumentera vilken hård- och mjukvara som används i informationssystemet och deras inbördes beroenden. Kraven gäller även informationssystem där en incident kan medföra synnerligen allvarlig skada för säkerhet. I nästa avsnitt beskrivs närmare de åtgärder som en verksamhets- utövare behöver genomföra innan driftsättning sker av informations- system som har betydelse för säkerhetskänslig verksamhet. 49Se 3 kap. 1–3 §§ säkerhetsskyddsförordningen (2018:658) och 3 kap. 1 § och 4 kap. 7–9, 25 och 26 §§ Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. Upprättad systemdokumentation är normalt en förutsättning för att få översikt över ett informationssystem. Det är också en förutsätt- ning för att effektivt kunna hantera driftrelaterade problem och in- cidenter. Systemdokumentationen är även ett hjälpmedel för att identifiera vilka delar av informationssystemet som berörs av en säker- hetsuppdatering som ska installeras, vilka delar som berörs av en in- träffad incident samt i övrigt för att kunna identifiera beroenden mellan olika komponenter i ett informationssystem. Verksamhetsutövaren ska upprätta systemdokumentation för in- formationssystemet innan det driftsätts. Systemdokumentation kan behövas i olika delar av en organisation, och den måste därför ut- formas på ett sådant sätt att den är till nytta för de olika avsedda mot- tagarna.50 Systemdokumentation bör även finnas i pappersform så att den är möjlig att ta del av även om den elektroniskt lagrade dokumen- tationen är otillgänglig, t.ex. vid större störningar i nätverken. 7.10.3Verifiering av funktions- och säkerhetskrav För att en verksamhetsutövare ska kunna säkerhetsställa att ett in- formationssystem som har betydelse för säkerhetskänslig verksam- het uppfyller säkerhetskraven och att de säkerhetskyddsåtgärder som identifierats i den särskilda säkerhetsskyddsbedömningen ger öns- kad effekt, behöver informationssystemet ha genomgått testning innan driftsättning. Resultatet av dessa ska jämföras mot verksamhetsut- övarens funktionella och säkerhetsrelaterade krav för informations- systemet. Detta är ett sätt att verifiera att informationssystemet upp- fyller de krav som verksamhetsutövaren fastställt. Kraven identifieras och fastställs av verksamhetsutövaren i den särskilda säkerhetsskydds- bedömningen, och i förkommande fall genom hotmodellering. Den särskilda säkerhetsskyddsbedömningen är ett styrande dokument för alla delar i utvecklingen av ett informationssystem som ska an- vändas i säkerhetskänslig verksamhet. Detta gäller inte minst i den 50Systemdokumentation kan innehålla bl.a.: –beskrivningar av informationssystemets arkitektur med ingående hård- och mjukvara (Solution Architecture Document, SAD), –förklaring av hur varje komponent inom systemet fungerar, och –beskrivningar av hur systemet bör underhållas och vad som ska göras vid vissa kända problem. del i utvecklingsprocessen där en verksamhetsutövare ska genomföra tester och säkerhetsgranskningar. Av 3 kap. 3 § säkerhetsskyddsförordningen framgår att ett informa- tionssystem som ska användas i säkerhetskänslig verksamhet inte får tas i drift förrän det har godkänts ur säkerhetsskyddssynpunkt av verksamhetsutövaren. Godkännandet ska dokumenteras. Under vissa omständigheter är en verksamhetsutövare skyldig att även samråda med Säkerhetspolisen innan ett informationssystem tas i drift eller i väsentliga avseenden förändras. 7.11.1Allmänt om drift och underhåll Arbetet med drift och underhåll av informationssystem avser dels att hantera olika driftrelaterade problem som kan uppstå, dels att tillse att säkerheten i informationssystemet upprätthålls . Viktiga delar i detta arbete är att tillse att informationssystemet hålls upp- dateras, att föråldrad programvara byts ut samt att förändringar och avveckling genomförs på ett kontrollerat sätt.51 Bestämmelser relaterade till drift och underhåll finns bl.a. i Säker- hetspolisens föreskrifter om säkerhetsskydd (PMFS 2019:2). 7.11.2Styrning av drift och underhåll För att tillgodose att säkerheten i ett informationssystem upprätt- hålls är det viktigt att en verksamhetsutövare har en tydlig styrning av hur drift och underhåll av ett informationssystem ska han- teras. Om drift och underhåll av ett informationssystem inte han- teras på ett medvetet och strukturerat sätt av verksamhetsutövaren, kan det leda till att systemets tillförlitlighet påverkas, t.ex. genom tillgänglighetsrelaterade problem eller andra sårbarheter i informa- tionssystemet. 51Se 3 kap. 4 § säkerhetsskyddsförordningen (2018:658) och 3 kap. 3, 25–27 §§ och 4 kap. 2, 10, 24, 34 och 38 §§ Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. Av bestämmelserna i 4 kap. 10 § i PMFS 2019:2 framgår att verk- samhetsutövaren ska fastställa rutiner för hanteringen av informa- tionssystem som har betydelse för säkerhetskänslig verksamhet under systemets förväntade livstid. Traditionellt styrs drift och underhåll av ett informationssystem med stöd av ett skriftligt ramverk som innehåller både över gripande principer och anvisningar för hur olika driftrelaterade frågor ska han- teras i praktiken. Oavsett styrmodell är det viktigt att styrdokumenten anpassas utifrån den egna verksamhetens förutsättningar och informa- tionssystemets komplexitet och omfattning. En allt för detaljreglerad styrning kan i vissa fall medföra att driften blir för svårhanterad, och en allt för svag reglering kan medföra att kontrollen över informa- tionssystemet blir bristfällig. Vid framtagande av styrning för hur drift av informationssystem bör verksamhetsutövaren bl.a. beakta perspektiven: Det är av vikt att verksamhetsutövaren etablerar tydliga roller med beskrivning av vem som gör vad, vem som har vilket ansvar och vem som har vilka befogenheter. I sammanhanget är det även av vikt att ansvaret för säkerheten i ett informationssystem tydligt anges. För- ändringar i styrande dokument för drift bör endast genomföras efter att de har godkänts av en kompetent och specifikt utpekad person eller funktion hos verksamhetsutövaren. Den praktiska hanteringen av driften av ett informationssystem bör, där det är tekniskt möjligt, hanteras konsekvent med samma verktyg och hjälpmedel. En grundläggande princip är att informationssystem som används i säkerhetskänslig verksamhet ska hållas uppdaterade så att säkerhets- brister och sårbarheter motverkas. I praktiken innebär detta att verk- samhetsutövaren måste förse både mjuk- och hårdvaran i informa- tionssystemet med de säkerhetsuppdateringar som publiceras av till- verkaren, samt i övrigt byta ut äldre versioner av programvara som kan förses med säkerhetsuppdateringar. Större förändringar i ett informationssystem, särskilt när ny programvara implemente- ras, kan påverka både säkerheten och tillgängligheten. Förändringar av befintlig programvara eller implementation av ny programvara som kan komma att påverka informationssystemet bör därför ske under kontrollerade former. En annan viktig aspekt att beakta vid förändringar i ett informationssystem är att förändringar inte genom- förs på ett sådant sätt som åsidosätter säkerhetsfunktioner i infor- mationssystemet, antingen tillfälligt eller permanent. Informationssystem som innehåller programvara som inte är upp- daterad är i många fall ett tacksamt mål för en hotaktör. Sårbarheter i programvaror identifieras löpande och blir ibland publikt kända redan innan tillverkaren av programvaran hunnit åtgärda sårbarheten och publicerat en säkerhetsuppdatering. Regelbunden uppdatering av programvara genom säkerhetsuppdateringar (s.k. säkerhetspatchar) är en åtgärd som utgör en del av det grundläggande skyddet av ett informationssystem. Syftet med säkerhetsuppdateringar är att användaren ska ha en möjlighet att åtgärda publikt kända sårbarheter i programvaran och på så sätt minska risker för att drabbas av ett angrepp via dessa. Hur en känd sårbarhet i programvara kan nyttjas av en hotaktör skiljer sig naturligtvis åt och beror till stor del på hur programvaran är implementerad och konfigurerad av användaren. Säkerhetsuppdateringar publiceras inte bara för mjukvara såsom applikationer och operativsystem, utan även för hårdvara i infrastruk- tur såsom exempelvis switchar, routrar och servrar. Av bestämmelserna i 4 kap. 24 § i PMFS 2019:2 framgår att verksam- hetsutövaren ska se till att programvara i informationssystem som har betydelse för säkerhetskänslig verksamhet hålls uppdaterad så att säkerhetsbrister och sårbarheter motverkas. Om det finns särskilda skäl får verksamhetsutövaren besluta om undantag från dessa krav. Informationssystem som innehåller föråldrade versioner eller utgåvor av programvara är också ett tacksamt mål för en hotaktör. När en tillverkare släpper en ny version eller utgåva av en program- vara upphör ofta publiceringen av säkerhetsuppdateringar till äldre versioner av programvaran. Äldre versioner av programvaran kan ha tillgång till support som fastställs av till- verkaren. Det är därför av vikt att verksamhetsutövaren har känne- dom om när tillverkarens support för en programvara upphör (s.k. ”end-of-life”) och har en plan för när avveckling av den föråldrade programvaran ska ske. Programvara som inte längre erhåller säker- hetsuppdateringar från tillverkaren bör därför avvecklas och ersättas. Ett informationssystem som hanterar säkerhetsskyddsklassifi- cerade uppgifter får inte anslutas direkt mot internet för hämtning av uppdateringar. Säkerhetsuppdateringar behöver därför hämtas till ett separat informationssystem och därefter, på ett kontrollerat sätt, föras över till informationssystemet som hanterar de säkerhetsskydds- klassificerade uppgifterna. Om möjligt bör ny programvara testas i ett informationssystem som är separerat från det informationssystem där programvaran ska installeras och användas. Detta ger verksamhetsutövaren möjlighet att testa och granska hur den nya programvaran beter sig, utan att det kan påverka informationssystemet som är i drift. Samma testför- farande bör om möjligt även tillämpas vid uppdatering av och utbyte av befintlig programvara. Informationssystem som beskrivs ovan be- nämns ofta i termer av testmiljö respektive driftsmiljö. 7.11.3Beslut om undantag av säkerhetsuppdateringar En grundläggande princip är att informationssystem som används i säkerhetskänslig verksamhet ska hållas uppdaterade så att säkerhets- brister och sårbarheter motverkas. Som ovan framgår innebär detta att verksamhetsutövaren måste förse både mjuk- och hårdvaran i in- formationssystemet med de säkerhetsuppdateringar som publiceras av tillverkaren, samt i övrigt byta ut äldre versioner av programvara som kan förses med säkerhetsuppdateringar. Om det finns särskilda skäl får en verksamhetsutövare besluta om undantag från kravet på att programvara i ett informationssystem som har betydelse för säkerhetskänslig verksamhet hålls uppdaterad. Så kan vara fallet om det inte är tekniskt möjligt att installera säker- hetsuppdateringarna eller i det fall verksamhetsutövaren konstaterat att det uppenbarligen är obehövligt då andra kompenserade åtgärder har vidtagits. Säkerhetskopiering är en livlina och det kan få stora konsekvenser om den är bristfällig, eftersom information som regel är en verksamhetsutövares viktigaste resurs. Brister i säkerhetskopier- ingen kan vid dataförlust åsamka verksamhetsutövaren stor skada. Även förlust av till synes ganska oviktig information kan skada verk- samheten. Verksamhetsutövaren bör därför ta fram rutiner för hur säkerhetskopiering ska hanteras. 7.12Allmänt om operativ säkerhet Med operativ säkerhet avses det operativa arbete som syftar till att upptäcka, försvåra och hantera skadlig inverkan på informations- systemet samt obehörig avlyssning av, åtkomst till och nyttjande av informationssystemet. Inom detta område är säkerhetsloggning, logg- uppföljning, säkerhetsövervakning och incidenthantering viktiga om- råden. Bestämmelser relaterade till operativt säkerhetsarbetet åter- finns i säkerhetsskyddsförordningen.