sou · H9B363 · 2021-07-02 00:00:00 — 7.5.2Hur ska informationssystemet användas? En särskild säkerhetsskyddsbedömning för ett informationssystem ska klarlägga vad informationssystemet ska användas till och av vem det ska användas, detta gäller också om informationssystem är avsett att användas i flera verksamheter. I vissa fall sker utveckling av infor- mationssystemet för en specifik verksamhet, men det är inte ovanligt att informationssystem kan komma att användas i andra verksamheter där behovet av säkerhetskyddsåtgärder är annorlunda. Förändringar av säkerhetsskyddsåtgärder som behöver ske i efter- hand kan medföra betydande kostnader och det är därför en fördel att verksamhetsutövaren har ett långsiktigt perspektiv och vid behov planerar för ett bredare användningsområde. 7.5.3På vilket sätt är informationssystemet av betydelse för säkerhetskänslig verksamhet? En verksamhetsutövare behöver även klarlägga på vilket sätt informa- tionssystemet har betydelse för säkerhetskänslig verksamhet. I denna bedömning kan olika frågeställningar bli aktuella för att identifiera berörda skyddsvärden: –ska säkerhetsskyddsklassificerade uppgifter behandlas i systemet? –vilken skada för säkerhet kan uppstå om uppgifterna som informationssystemet behandlar röjs? –ska informationssystemet behandla uppgifter som omfattas av ett för förpliktande internationellt åtagande om säkerhets- skydd? –vilken skada för säkerhet kan uppstå om uppgifterna som informationssystemet ska behandla görs otillgängliga eller obe- hörigen förändras? Säkerhetsskyddsklassificering och vad som framgår av verksamhets- utövarens säkerhetsskyddsanalys är viktiga ingångsvärden för be- dömningen. 7.5.4Hur exponeras informationssystemet mot andra informationssystem? I bedömningen kan verksamhetsutövaren även behöva analysera hur informationssystemet kan komma att exponeras mot och interagera med andra informationssystem. Verksamhetsutövaren kan dokumen- tera detta genom att ta fram en övergripande design som beskriver hur informationssystemet ska kommunicera med andra informations- system och andra logiska samband som finns till informationssystemet. 7.5.5Vilka säkerhetskrav gäller för informationssystemet? När samtliga skyddsvärden är identifierade och bedömda ska kraven på säkerhet fastställas för skyddet av informationssystemet. Dessa krav framgår främst av bestämmelserna i säkerhetsskyddslagen (2018:585), säkerhetsskyddsförordningen (2018:658) och i Säkerhets- polisens föreskrifter (PMFS 2019:2) om säkerhetsskydd samt För- svarsmaktens föreskrifter om säkerhetsskydd (FFS 2019:2) Fort- sättningsvis refereras i första hand till Säkerhetspolisens föreskrifter om informationssäkerhet i säkerhetskänslig verksamhet. I Försvars- maktens förskrifter finns i allt väsentligt motsvarande bestämmelser om informationssäkerhet och de gäller inom myndighetens tillsyns- område. Vilka krav som är tillämpliga beror på vilken typ av säkerhets- skyddsklassificerade uppgifter som ska hanteras i informationssyste- met. Om informationssystemet även ska behandla uppgifter som omfattas av ett för förpliktande internationellt åtagande om säkerhetsskydd måste också de krav som följer av den internationella överenskommelsen identifieras och dokumenteras. 7.5.6Vilka säkerhetsskyddsåtgärder behöver införas i och kring informationssystemet? När säkerhetskraven är identifierade måste verksamhetsutövaren ana- lysera vilka säkerhetsskyddsåtgärder som är motiverade att vidta i och kring informationssystemet. De krav på säkerhetsskyddsåtgärder som följer av bestämmel- serna i de angivna författningarna kräver ofta en bredare analys för att fastställa på vilket sätt de ska tillämpas. Det framgår t.ex. inte av bestämmelserna var i ett informationssystem säkerhetskyddsåtgär- derna ska appliceras och hur de ska dimensioneras. Huvudprincipen är att säkerhetsskyddsåtgärderna ska anpassas utifrån det högsta identifierade skyddsvärdet som informationssyste- met avser att hantera, vilken hotbild som föreligger mot dessa skydds- värden, hur och av vem informationssystemet ska användas samt hur det ska exponeras. Det kan därutöver finnas skäl till att vidta ytter- ligare säkerhetsåtgärder än vad som framgår av författningarna. När behovet av säkerhetsskyddsåtgärder analyseras bör en utgångs- punkt vara att de utformas så att de kompletterar och överlappar varandra, dvs. säkerhetsskyddsåtgärderna bör byggas i flera lager. För- delen med detta är att även om en säkerhetsskyddsåtgärd visar sig vara otillräcklig, finns flera andra säkerhetsskyddsåtgärder som kan träda in och exempelvis förhindra ett försök till intrång.23 I följande avsnitt redogörs översiktligt för några olika säkerhets- skyddsåtgärder som kan implementeras i ett informationssystem som har betydelse för säkerhetskänslig verksamhet.24 En verksamhetsutövare måste förhålla sig till de hot som ett infor- mationssystem kan vara exponerat mot och de sårbarheter som finns i och kring informationssystemet. För att en verksamhetsutövare ska kunna få en uppfattning om nya eller förändrade hot, uppkomst av nya sårbarheter, t.ex. i programvaror som används, behöver verk- 23Inom engelsk facklitteratur brukar denna princip beskrivas som defence in depth. 24Se Säkerhetspolisens Vägledning i säkerhetsskydd, Informationssäkerhet, 2020, och Försvars- maktens , Informationssäkerhet, H Säk Infosäk, 2013. samhetsutövaren löpande bevaka händelser i omvärlden som kan påverka säkerheten i verksamhetsutövarens informationssystem. Bestämmelser om omvärldsbevakning finns i Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. I 4 kap. 2 § anges att verksamhetsutövaren ska kontinuerligt anpassa säkerhetsskyddsåt- gärder i informationssystem för att möta förändringar av hot och sårbarheter. Verksamhetsutövaren ska även fastställa hur detta ska genomföras och vem som ansvarar för att identifiera förändringarna. Denne behöver därför ha förmåga att bedöma hur en sårbarhet, t.ex. i en programvara, kan påverka säkerheten i verksamhetsutövarens informationssystem och därefter ta ställning till om sårbarheten be- höver åtgärdas omgående eller inte. De stora tillverkarna av programvara publicerar normalt säker- hetsuppdateringar (s.k. säkerhetspatchar) när en sårbarhet i en pro- gramvara blir känd. Tillverkaren har ofta redan gjort någon form av värdering av hur allvarlig sårbarheten är som säkerhetsuppdateringen ska åtgärda, vilket kan ligga till grund för verksamhetsutövarens be- dömning av hur sårbarheten kan påverka verksamhetsutövarens in- formationssystem. Information om nya attackmetoder och sårbarheter i hård- och mjukvara publiceras löpande i omvärlden och det kan därför vara svårt att manuellt inhämta och distribuera denna typ av information. Som stöd i detta kan en verksamhetsutövare behöva använda ett system som automatiskt hämtar in och distribuerar relevant infor- mation till berörd personal. Oavsett om omvärldsbevakning sker manuellt eller med ett tekniskt stöd är det av vikt att verksamhets- utövaren har en inventarieförteckning för den mjuk- och hårdvara som förekommer i verksamhetsutövarens informationssystem efter- som det annars kan uppstå problem för verksamhetsutövaren att veta vilka sårbarheter som är relevanta att ta ställning till. Om en verksamhetsutövare ska ha förutsättningar att kunna hålla ett informationssystem i drift och upprätthålla säkerheten krävs både resurser och kompetens. Utan en planering för detta riskerar säker- hetsarbetet att åsidosättas. Bestämmelser relaterade till kompetens och resursplanering återfinns i Säkerhetspolisens föreskrifter om säker- hetsskydd (PMFS 2019:2). Av bestämmelserna i 2 kap. 16 § PMFS 2019:2 framgår att verk- samhetsutövaren ska säkerställa att det finns resurser och kompeten- ser tillgängliga i den utsträckning som krävs för att upprätthålla säker- hetsskyddet. Av bestämmelserna i 4 kap. 3 § PMFS 2019:2 framgår att verk- samhetsutövaren ska se till att den som deltar i utveckling, framtag- ning av arkitektur, testning och drift av informationssystem som har betydelse för säkerhetskänslig verksamhet har tillräcklig kompetens avseende informationssäkerhet och sårbarheter i aktuellt informa- tionssystem. Utveckling av informationssystem eller mjukvara i ett informa- tionssystem kan ske i olika plattformar och baseras på en mängd olika programmeringsspråk. Var och en av dessa it-plattformar kan ha inne- boende sårbarheter som både kan nyttjas av en hotaktör vid ett an- grepp och som kan påverka driftsäkerheten i informationssystemet. Den som deltar i utveckling av informationssystem måste av därför ha adekvat och aktuell kompetens om de sårbarheter som finns i de plattformar där utveckling sker för att sårbarheter ska kunna om- händertas. Motsvarande förhållningssätt till kompetens gäller även för den som arbetar med drift av informationssystem. Utveckling av informationssystem är ett arbete som ofta bedrivs i projektform av ett utvecklingsteam som är skräddarsytt för det specifika utveck- lingsprojektet. Inte sällan är den personal som utvecklar informa- tionssystemet inhyrd eller i övrigt organisatoriskt frånskild från den personal som ska arbeta med drift och förvaltning av informations- systemet. Av denna anledning är det av vikt att den mottagande orga- nisationen (driftorganisationen) som ska arbeta med drift och för- valtning av informationssystemet har rätt kompetenser och resurser innan informationssystemet tas i drift. Detta bidrar även till att drift- organisationen kan upprätthålla tillräcklig funktionalitet och säker- hetsskydd för informationssystemet . Verksamhetsutövaren bör därför innan ett informationssystem av betydelse för säkerhets- känslig verksamhet tas i drift planera för drift och förvaltning av informationssystemet. I detta ligger att fastställa vilka resurser och kompetenser som erfordras för drift och förvaltning av informations- systemet. Att utbildning av personal eller nyrekryteringar tar tid och är ytterligare aspekt, varför planeringen för drift och förvaltning bör ske på ett tidigt stadium. I 8 § anges att verksamhetsutövaren även ska – innan ett informa- tionssystem som har betydelse för säkerhetskänslig verksamhet tas i drift – dokumentera de resurser och kompetenser som krävs för att bibehålla fastställt säkerhetsskydd under informationssystemets för- väntade livstid. 7.7.1Allmänt om utveckling av informationssystem Att utveckla ett informationssystem som har betydelse för säker- hetskänslig verksamhet kan vara en resurs- och tidskrävande akti- vitet. Det kräver en tydlig kravbild utifrån en särskild säkerhetsskydds- bedömning, men också ett strukturerat arbetssätt och god kompetens om de risker och sårbarheter som kan kopplas till de plattformar i vilket utvecklingen sker. 7.7.2Behovet av process för utveckling av informationssystem Utveckling av informationssystem som ska användas i säkerhets- känslig verksamhet är en aktivitet som kräver noggrann planering och ett systematiskt arbetssätt. Om verksamhetsutövaren inte tar fram en egen process för utvecklingen, finns vedertagna koncept och pro- cesser för hur utveckling av ett informationssystem kan genomföras. Oavsett vilken metod eller process som används vid utveckling behöver verksamhetsutövaren planera med ett långsiktigt perspektiv för hanteringen av informationssystemet, dvs. från utvecklingen av systemet till avveckling av detsamma (systemets livscykel).25 En sådan process bör bl.a. innefatta: 25Ett exempel på en sådan process utgör Software Development Life Cycle (SDLC), som är en vedertagen term för att beskriva en utvecklingsprocess där säkerhet tas i beaktande genom utvecklingsprocessens alla faser. –drift, och –avveckling av ett informationssystem. Oavsett val av modell för utveckling är det viktigt att verksamhets- utövaren säkerställer en integration av säkerhetsarbetet som en natur- lig del av utvecklingsprocessen för att tillvarata säkerhetsskydds- kraven i hela livscykelperspektivet för informationssystemet. Allmänt om systemdesign och systemutveckling Genom att införa olika säkerhetsrelaterade aktiviteter i varje steg under en utvecklingsprocess för ett informationssystem ökar möj- ligheterna att uppnå en ändamålsenlig och kostnadseffektiv säkerhet. För att uppnå en säker systemdesign och systemutveckling behöver ett antal aktiviteter genomföras, t.ex.: –utbildning av utvecklare i säker systemutveckling (kodning, kod- hantering och ramverk), –statisk och dynamisk kodanalys. Verksamhetsutövaren bör även upprätta en separation av utvecklings- miljön från test- och produktionsmiljöerna.26 Hotmodellering är en process där potentiella tillvägagångssätt som en hotaktör kan tänkas nyttja för att angripa ett informationssystem identifieras.27 Syftet med hotmodellering är att utifrån en systematisk 264 kap. 4 och 5 §§ Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. 27Organisationen har tagit fram ett ramverk (ATT&CK framework) som beskriver olika attackmetoder, vilka kända aktörer som använt dessa och hur de kan motverkas eller upptäckas. analys få en bild av vilka typer av angrepp en verksamhetsutövare kan drabbas av. Vid genomförandet av en hotmodellering identifieras systemets olika komponenter, kommunikationsvägar, flöden av data och potentiella hot samt attacker mot dessa. Detta arbete ska resul- tera i en lista med säkerhetsfunktioner som ska implementeras och potentiella säkerhetsbrister som ska hanteras i den fortsatta utveck- lingen av informationssystemet. En sådan hotmodellering kan t.ex. göras i samband med framtagandet av den särskilda säkerhetsskydds- bedömningen för informationssystemet. Säker kodning och kodhantering Vid systemutveckling bör man utveckla arbetssätt som ger god kod- kvalitet och stabil funktionalitet, t.ex. kan det ske i testdriven utveck- ling, där koden kontrolleras löpande för att upptäcka säkerhetsbris- ter. En verksamhetsutövare kan t.ex. använda automatiserad statisk kodanalys för att identifiera enklare säkerhetsbrister i koden. Ut- vecklaren får då information om vilka problem som upptäckts i käll- koden och hur dessa kan åtgärdas. Verksamhetsutövaren kan även genomföra återkommande kodgranskning under hela utvecklings- processen. Proprietära28 säkerhetslösningar tenderar ofta att bli sårbara. Av denna anledning bör standardiserade och väletablerade produkter, protokoll och algoritmer i den omfattning det är möjligt användas. Vid utveckling av informationssystem bör även standardiserade och välbeprövade programvarubibliotek användas. Tredjepartsbibliotek används ofta i utvecklingsprojekt för att skynda på utvecklingen, då dessa kan erbjuda en genväg för att uppnå en viss funktionalitet. Dessa bibliotek bör dock granskas innan de inklu- deras i projektet då de kan innehålla sårbarheter. Har hunnit användas brett i projektet kan det vara svårt att ta bort eller byta ut i efterhand. Det är även viktigt att alla tredjeparts- bibliotek som används i projektet kontinuerligt uppdateras, så att even- tuella säkerhetsuppdateringar som publiceras inkluderas i projektet. 28Proprietär programvara är programvara som har restriktioner, t.ex. satta av ägaren, vad gäller att använda, modifiera eller kopiera. Med begreppet arkitektur i ett informationssystem avses vanligen en detaljerad specifikation över vilka ingående komponenteter ett in- formationssystem ska bestå av och gränssnitten mellan dessa. Kom- ponenter kan exempelvis utgöras av hårdvara, t.ex. infrastrukturkom- ponenter, eller mjukvara i form av applikationer och plattformar. Ett gränssnitt kan t.ex. vara kommunikationsprotokoll eller hur kom- ponenterna ska sammankopplas rent fysiskt. Med begreppet arkitektur avses även uppbyggnaden inom ett in- formationssystem, exempelvis i fråga hur olika entiteter inom infor- mationssystem tillåts kommunicera med varandra, samt beroenden mellan entiteter. Ett informationssystem och programvaror och komponenter som ingår i det innehåller i regel både kända och okända sårbarheter som under vissa omständigheter kan nyttjas av en hotaktör. Vilken insats som krävs av en hotaktör för att utnyttja en sådan sårbarhet är till stor del beroende av hur informationssystemet exponeras. Ett informationssystem som inte kommunicerar med något annat informationssystem har generellt sett en låg grad av exponering gent- emot externa hotaktörer. Ett informationssystem som kommunicerar med ett eller flera andra informationssystem har däremot en högre exponering, vilket också öppnar upp fler möjliga vägar till angrepp. För att minska exponering av informationssystem som innehåller säkerhetsskyddsklassificerade uppgifter är separation mellan infor- mationssystem en viktig säkerhetsskyddsåtgärd. Bestämmelser relaterade till separation av informationssystem återfinns i Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhets- skydd. Av bestämmelserna i 4 kap. 20 § i PMFS 2019:2 framgår att verk- samhetsutövaren ska se till att informationssystem som är avsett för att behandla säkerhetsskyddsklassificerade uppgifter i säkerhetsskydds- klassen begränsat hemlig eller konfidentiell, logiskt separeras från infor- mationssystem eller nätverk som inte omfattas av motsvarande krav på säkerhetsskydd. Av 21 § samma föreskrifter framgår att verksamhetsutövaren ska se till att informationssystem som är avsett för att behandla säker- hetsskyddsklassificerade uppgifter i säkerhetsskyddsklassen hemlig eller kvalificerat hemlig, fysiskt separeras från informationssystem eller nätverk som inte omfattas av motsvarande krav på säkerhetsskydd. Informationssystem som är avsett för att behandla säkerhetsskydds- klassificerade uppgifter i säkerhetsskyddsklassen hemlig eller kvalifi- cerat hemlig, ska tillåta endast envägskommunikation vid import re- spektive export av data. Med logisk separation avses att möjligheten till kommunikation mellan informationssystem förhindras med stöd av mjuk- eller hård- vara. En verksamhetsutövare ska säkerställa att ett informations- system som är avsett för att behandla säkerhetsskyddsklassificerade uppgifter i säkerhetsskyddsklassen begränsat hemlig eller konfiden- tiell, logiskt separeras från informationssystem eller nätverk som inte omfattas av motsvarande krav på säkerhetsskydd. Ett informationssystem avsett för att behandla säkerhetsskydds- klassificerade uppgifter i säkerhetsskyddsklassen begränsat hemlig eller konfidentiell kan i vissa fall dela infrastrukturkomponenter med ett informationssystem som inte omfattas av säkerhetsskydd. De tekniska lösningar som finns tillgängliga för att dela infrastruktur medför både risker och sårbarheter som en verksamhetsutövare be- höver hantera. Att dela infrastrukturkomponenter mellan sådana in- formationssystem bör därför ske restriktivt. Vid logisk separation föreligger bl.a. följande risker: –sårbarheter i tekniken, –sårbarheter i implementationen av tekniken, –felaktiga konfigurationer. Om den virtuella infrastrukturen delas mellan ett informationssystem som behandlar säkerhetsskyddsklassificerade uppgifter och ett infor- mationssystem som inte omfattas av säkerhetsskydd kan en hotaktör angripa den virtuella infrastrukturen och får åtkomst till det andra informationssystemet med hjälp av en sårbarhet i det ena informa- tionssystemet. Även om informationssystem avsedda för att behandla säkerhets- skyddsklassificerade uppgifter i säkerhetsskyddsklassen begränsat hem- lig eller konfidentiell inte ska kommunicera med informationssystem eller nätverk som saknar motsvarande krav på säkerhetsskydd, före- ligger ibland behov av sådan kommunikation. Om sådan kommu- nikation ska kunna realiseras måste verksamhetsutövaren ansöka om undantag. Både Säkerhetspolisen och tillsynsmyndigheterna har möj- lighet att medge undantag från bestämmelserna i föreskrifter (PMFS 2019:2) om säkerhetsskydd. Innan en tillsyns- myndighet fattar beslut om undantag ska myndigheten samråda med Säkerhetspolisen. Med fysisk separation avses att ett informationssystem inte har några fysiska sammankopplingar med ett annat informationssystem, om det inte omfattas av motsvarande krav på säkerhetsskydd. En verksamhetsutövare ska se till att informationssystem som är avsett för att behandla säkerhetsskyddsklassificerade uppgifter i säker- hetsskyddsklassen hemlig eller kvalificerat hemlig, fysiskt separeras från informationssystem eller nätverk som inte omfattas av motsva- rande krav på säkerhetsskydd. 7.7.6Import och export av data Om data ska importeras till informationssystem avsett för att behandla säkerhetsskyddsklassificerade uppgifter i säkerhetsskyddsklassen be- gränsat hemlig eller konfidentiell, från ett informationssystem som inte omfattas av säkerhetsskydd, behöver verksamhetsutövaren tillse att import görs på ett sådant sätt att informationssystemen inte kan kommunicera med varandra. En metod för genomföra sådan import kan vara att importera data via bärbar lagringsmedia. För informationssystem avsett för att behandla säkerhetsskydds- klassificerade uppgifter i säkerhetsskyddsklassen hemlig eller kvalifi- cerat hemlig, får import och export av data endast ske via envägskom- Med envägskommunikation avses att information enbart kan flöda åt ett håll. Om import och export behöver utföras sam- tidigt ska dessa funktioner, så långt det är möjligt, separeras för att göra det svårt att öppna upp en dubbelriktad kommunikationskanal. Vid import av data kan verksamhetsutövaren behöva en funktion som kan detektera förekomst av skadlig kod, eller på annat sätt veri- fiera integriteten i data som importeras. Ett tillvägagångsätt kan vara att exekvera data i ett fristående informationssystem, s.k. sandlåda (sand box). Med denna metod kan verksamhetsutövaren kontrollera innehållet och i förkommande fall ”tvätta” filerna eller förhindra filerna från att importeras. 7.7.7Säkerhetszoner och kontrollerad kommunikation Ett sätt att minska exponeringen av ett informationssystem är att säkerställa att det kommunicerar på ett kontrollerat sätt. Ett infor- mationssystem av betydelse för säkerhetskänslig verksamhet bör där- för utformas enligt principen om kontrollerad kommunikation. Med detta avses att verksamhetsutövaren först fastställer hur och på vilket sätt ett sådant informationssystem får kommunicera. Därefter bör verksamhetsutövaren införa lämpliga säkerhetskyddsåtgärder som säkerhetsställer att informationssystem endast tillåts kommunicera på ett kontrollerat sätt. Bestämmelser relaterade till kontrollerad kommunikation återfinns i Säkerhetspolisens föreskrifter (PMFS 2019:2) om säkerhetsskydd. Av bestämmelserna i 4 kap. 19 § framgår att verksamhetsutövaren ska se till att informationssystem som har betydelse för säkerhetskänslig verksamhet kommunicerar på ett kontrollerat sätt med komponen- ter eller delsystem inom samma informationssystem, och kommuni- cerar på ett kontrollerat sätt med informationssystem eller nätverk som inte omfattas av krav på säkerhetsskydd. Ett teoretiskt koncept som brukar användas för att åskådliggöra olika principer för att minska exponeringen av ett informationssystem är att modellera olika säkerhetszoner. I denna kontext placeras ett in- formationssystem i en säkerhetszon baserat på hur skyddsvärt det är. Säkerhetskyddssåtgärder bör säkerställa att endast tillåten kommu- nikation kan ske från en zon till en nästliggande zon.29 Informations- system som omfattas av motsvarande krav på säkerhetsskydd kan placeras i samma säkerhetszon. En hotaktör med ett slumpmässigt mål har oftast inte kunskap och resurser som krävs för att få åtkomst till de mest skyddsvärda zonerna. En målinriktad hotaktör med mer kunskap och resurser kan försöka komma åt de mer skyddsvärda informationssystemen. En avancerad hotaktör kan förfoga över stora resurser, vilket kan möj- liggöra kompromettering av det mest skyddsvärda informations- systemen. Informationssystem kan i vissa fall vara placerade inom samma säkerhetszon och kan kommunicera direkt med varandra och dela infrastrukturkomponenter. Kommunikation mellan dessa bör dock ske på ett kontrollerat sätt, t.ex. med hjälp av brandvägg.