Rekommendation för informationssäkerhet och teknisk IT-säkerhet

1.2.5 Rekommendationer

Samtliga aktörer behöver själva utforma och etablera informationssäkerhetsklassning baserat på egna interna regler och arbetssätt för behandling av information samt informationssystem som ansluter och agerar i Plattformen och dess federationer.

Samtliga aktörer behöver själva löpande analysera, bedöma och vidta de åtgärder som lagar och förordningar ställer på den egna verksamheten hos respektive aktör/roll utifrån den informationssäkerhetsklassning och riskhantering som behöver göras för att säkerställa skyddsbehov och säkerhetsåtgärder för behandling av information med hänsyn till känslighetsnivå utifrån dataskydd och säkerhetsskydd.

1.3 Riskbaserat informationssäkerhetsarbete

Syftet med ett systematiskt och riskbaserat informationssäkerhetsarbete är att säkerställa kvalitet och trygghet i skydd av information och behandling av information i den egna verksamheten utifrån identifierande risker, hot, och sårbarheter.

1.3.1 Principer

[A] Ett informationssäkerhetsarbete utformas utifrån de risker, hot och sårbarheter en aktör identifierar för den verksamhet som bedrivs.

[B] Risker bedöms genom analys och värdering av skyddsbehov och säkerhetsåtgärder för information och behandling av information.

[C] Ett informationssäkerhetsarbete bedrivs baserat på egna interna regler som motsvarar de risker, hot, och sårbarheter som identifieras.

[D] Ett riskbaserat informationssäkerhetsarbete stödjer tillit för andra aktörer som är anslutna till och agerar i plattformen och berörd federation.

1.3.2 Rekommendationer enligt MSBFS2020:6. 5 och 14§

När aktörer utformar och etablerar informationssäkerhetsarbete bör den säkerställa att

1. informationssäkerhetsarbetet tilldelas nödvändiga resurser,
2. egna interna regler och arbetssätt upprättas,
3. egna interna regler och arbetssätt motsvarar identifierade och bedömda risker, hot och sårbarheter,
4. informationssäkerhetsarbetet följs upp och utvärderas regelbundet,
5. kontakt och eskaleringsvägar finns upprättade till berörda aktörer.

1.3.3 Rekommendationer

Samtliga aktörer behöver själva utforma och etablera ett systematiskt riskbaserat informationssäkerhetsarbete baserat på egna interna regler och arbetssätt som motsvarar identifierade och bedömda risker, hot och sårbarheter.

Samtliga aktörer behöver själva löpande bedriva ett systematiskt riskbaserat informationssäkerhetsarbete genom att analysera, värdera, hantera och följa upp risker, hot och sårbarheter samt vidta åtgärder.

1.4 Felhantering och support

Syftet med felhantering och support är att skyndsamt upptäcka fel och bedöma behov av support samt bedöma om fel skall rapporteras vidare.

1.4.1 Principer

[A] Hantering av fel säkerställs genom att skyndsamt upptäcka och bedöma fel och behov av support.

[B] Fel och behov av support hanteras, bedöms, klassificeras och eskaleras enligt egna regler samt lagar och förordningar.

[C] Fel och behov av support rapporteras vidare enligt utförda bedömningar och egna samt gemensamma rapporteringsvägar.

[D] Återkommande fel och behov av support utgör skäl till att genomföra översyn av säkerhetsåtgärder och motverka att det händer igen.

1.4.2 Rekommendationer

Samtliga aktörer behöver själva fastställa, dokumentera, införa, och kontinuerligt kontrollera och utvärdera förmågan att skyndsamt upptäcka och bedöma fel och behov av support samt bedöma om inträffat fel och behov av support behöver rapporteras externt.

1.5 Incidenthantering

Syftet med incidenthantering är att skyndsamt upptäcka och bedöma avvikelser, vid behov återställa samt bedöma om avvikelsen skall rapporteras vidare.

1.5.1 Principer

[A] Hantering av incidenter och avvikelser säkerställs genom att skyndsamt upptäcka och bedöma avvikelser och återställa manipulerad eller förlorad information.

[B] Incidenter och avvikelser hanteras, bedöms, klassificeras och eskaleras enligt egna regler samt lagar och förordningar.

[C] Incidenter och avvikelser rapporteras vidare enligt utförda bedömningar och egna samt gemensamma rapporteringsvägar.

[D] Återkommande incidenter och avvikelser utgör skäl till att genomföra översyn av säkerhetsåtgärder och motverka att det händer igen.

1.5.2 Rekommendation enligt MSBFS2020:6, 11 §:

Aktörer bör kunna

1. skyndsamt upptäcka och bedöma incidenter och avvikelser,
2. återställa manipulerad eller förlorad information, och
3. bedöma om inträffad incident ska rapporteras vidare enligt gällande kontaktvägar.

Rekommendation enligt MSBFS2020:6, 12 §:

Aktörer bör kunna identifiera grundorsaker till incidenter eller avvikelser och vidta åtgärder för att motverka att liknande incidenter och avvikelser inträffar på nytt.

1.5.3 Rekommendationer

Samtliga aktörer behöver själva fastställa, dokumentera, införa, och kontinuerligt kontrollera och utvärdera förmågan att skyndsamt upptäcka och bedöma incidenter och avvikelser, återställa manipulerad eller förlorad information, och bedöma om inträffad incident behöver rapporteras externt.

1.6 Spårbarhet och Logghantering

Syftet med loggning, spårbarhet och logghantering är att skapa bevis för inträffade händelser och producera en spårbarhetskedja som kan användas för analys, uppföljning och hantering av fel, avvikelser samt incidenter.

1.6.1 Principer

[A] Bevis för inträffade händelser säkerställs genom loggning som producerar en spårbarhetskedja som används för uppföljning och hantering av fel, avvikelser samt incidenter.

[B] Analys av loggar används för att kontinuerlig upptäcka och hantera incidenter och avvikelser samt fel.

1.6.2 Rekommendationer deltagare

Aktörer ska vid förfrågan från annan aktör vara behjälplig med att ta fram och lämna ut relevant logginformation, under förutsättning att den part som har efterfrågat logginformationen har ett berättigat intresse av dem och att aktören inte enligt lag eller annan författning är förhindrad att lämna ut dessa.

Aktörer bör logga minst följande informationsrelaterade händelser

1. Obehörig åtkomst och försök till obehörig åtkomst till information.
2. Åtkomst till information som bedömts ha behov av utökat skydd.

1.6.3 Rekommendationer

Samtliga aktörer behöver själva genom loggning skapa bevis för inträffade informationsrelaterade händelser som kan användas för analys, uppföljning och hantering av fel, avvikelser samt incidenter.

Samtliga aktörer behöver själva regelbundet analysera innehållet i säkerhetsloggarna för att kontinuerligt upptäcka och hantera incidenter och avvikelser samt fel.

1.7 Servicenivåer

Syftet med servicenivåer är att kunna mäta tillgänglighet i form av service och kvalitet enligt förväntade nivåer.

1.7.1 Principer

[A]Mätbara parametrar skapar möjlighet till servicenivåer för tillgänglighet.

[B] Grundläggande servicenivåer finns för miljöer och komponenter i Plattformen.

[C] SLA:er och ytterligare servicenivåer kan avtalas mellan aktörer vid behov.

1.7.2 Rekommendationer

Samtliga aktörer behöver själva via egna interna rutiner fastställa, dokumentera, införa, och kontinuerligt mäta tillgänglighet för service och kvalitet för uppföljning av behandling av information samt informationssystem till Plattformen och dess anslutna federationer.

1.8 Kontinuitetshantering för informationssystem

Syftet med kontinuitet är att under och efter svåra situationer, incidenter och kriser kunna upprätthålla fungerande informationssystem för behandling av information enligt i förväg accepterad omfattning och servicenivåer.

1.8.1 Principer

[A] Förmågan att upprätthålla kontinuitet under och efter svåra situationer, incidenter och kriser säkerställs genom att förmågan fastställas, dokumenteras, införs, och kontinuerligt kontrolleras och utvärderas.

[B] Förmågan att upprätthålla kontinuitet som fastställs i konsekvensanalys beror på servicenivåer såsom Maximalt tolerabla avbrottsperioder, Mål för återställningstid och återställningspunkt.

1.8.2 Rekommendation enligt MSBFS2020:6, 13 §:

Aktörer bör i sitt kontinuitetsarbete

1. utvärdera och omhänderta tillgänglighetskraven från genomförd informationsklassning,
2. identifiera aktörens behov av uthållighet över tid,
3. beakta behovet av att tillämpa alternativa arbetssätt, och
4. tydliggöra hur beslut om att tillämpa alternativa arbetssätt respektive beslut om att återgå till normal verksamhet fattas.

1.8.3 Rekommendationer

Samtliga aktörer behöver själva fastställa, dokumentera, införa, och kontinuerligt kontrollera och utvärdera förmågan att upprätthålla kontinuitet under svåra situationer, incidenter och kriser enligt i förväg accepterad omfattning och servicenivåer.

Samtliga aktörer behöver själva utföra konsekvensanalys för att skapa en förståelse för hur svåra situationer, incidenter och kriser påverkar verksamhetens operativa förmåga och möjligheten att uppnå fastställda servicenivåer och verksamhetsmål. (BIA - ”Business Impact Analysis”).

1.9 Granskning av informationssäkerhetsåtgärder

Syftet med granskning av de informations­säkerhets­åtgärder som plattformen och berörd federation erbjuder är att säkerställa att den egna verksamhetens krav på informationssäkerhetsåtgärder uppfylls vid anslutning till och agerande i en federation.

1.9.1 Principer

[A] Krav på att informationssäkerhetsåtgärder uppfylls vid anslutning till och agerande i en federation säkerställs genom egen granskning av de informations­säkerhets­åtgärder som plattformen och berörda federation erbjuder.

1.9.2 Rekommendationer

Samtliga aktörer behöver själva granska av de informations­säkerhets­åtgärder som plattformen och federationer erbjuder för att säkerställa att aktörens krav på informationssäkerhetsåtgärder uppfylls vid anslutning till och agerande i en federation.

1.10 Arkivering av dokumenterad information

Syftet med att arkivera dokumenterad information är att möjliggöra framtida användning samt att skydda den från förlust, förstörelse, förfalskning, obehörig åtkomst och otillåten utgivning.

1.10.01 Principer

[A] Dokumenterad information arkiveras och gallras i enlighet med författningsenliga, avtalsmässiga, verksamhetsmässiga krav samt servicenivåer.

[B] Dokumenterad information hanteras enligt av aktören utfärdade riktlinjer för lagring, arkivering, och gallring.

[C] Dokumenterad information arkiveras i form av säkerhetsrelaterade händelser, krypteringsnycklar samt datamängder som lagras och tillhandahålls i aktuell aktörs tjänster.

1.10.02 Rekommendationer enligt ISO 27002, 18.1.3:

Aktörer bör utfärda riktlinjer för lagring, arkivering, hantering och gallring av dokumenterad information;

1.10.3 Rekommendationer

Samtliga aktörer behöver själva arkivera och gallra dokumenterad information i enlighet med författningsenliga, avtalsmässiga, verksamhetsmässiga krav samt servicenivåer.

1.11 Avveckling av dokumenterad information och lagringsmedia

Syftet med avveckling av dokumenterad information och lagringsmedia samt utrustning som informationssystem består av är att minimera risken för läckage av konfidentiell information till obehöriga personer.

1.11.1 Principer

[A] För att minimera risken för läckage avvecklas dokumenterad information och lagringsmedia med stöd av interna rutiner.

[B] För att minimera risken för läckage avvecklas utrustning som informationssystem består av med stöd av interna rutiner.

[C] Avveckling sker i proportion till bedömda risker för känslighet och konfidentialitet.

1.11.2 Rekommendationer

Samtliga aktörer behöver själva avveckla dokumenterad information och lagringsmedia på ett säkert sätt för att minimera risken för läckage av information till obehöriga personer med stöd av interna regler i proportion till bedömda risker för känslighet och konfidentialitet.

Samtliga aktörer behöver själva avveckla utrustning som informationssystem består av på ett säkert sätt för att minimera risken för läckage av information till obehöriga personer med stöd av interna regler i proportion till bedömda risker för känslighet och konfidentialitet.

2. Teknisk IT-säkerhet

Beskrivning av funktioner för teknisk IT-säkerhet samt rekommendationer övergripande för samtliga aktörer inom SDK med målsättning att skapa tillit mellan aktörer. Detaljerade regler finns i varje aktörs regelverk.

Kontroll sker per aktörsroll genom anslutningsförfarande, övervakning och efterlevnadskontroll.

2.1 Uppdelning i nätverkssegment

Syftet med att placera informationssystem med olika funktioner i separata nätverks-segment är att förhindra spridning av incidenter och minska konsekvenser av angrepp.

2.1.1 Principer

[A] Informationssystem med olika funktioner placeras i separata nätverkssegment i produktionsmiljöer.

[B] Informationssystem med olika funktioner placeras i separata nätverkssegment även för utvecklings-, test- och utbildningsmiljö och hanteras separat av varje enskild aktör.

2.1.2 Rekommendationer enligt MSBFS2020:7, 4.1 §:

Följande funktioner i produktionsmiljön bör placeras i separata nätverkssegment:

1. Klienter för användare.
2. Klienter för administration.
3. Servrar.
4. Centrala systemsäkerhetsfunktioner i form av behörighetskontrollsystem, säkerhetsloggning, filtrering och liknande.
5. Centrala stödfunktioner i form av skrivare, scanner och liknande.
6. Trådlösa nätverk.
7. Gästnätverk.
8. Externt åtkomliga tjänster.
9. Informationssystem som sammankopplas med informationssystem hos extern aktör.
10. Industriella informations- och styrsystem.
11. System som innehåller sårbarheter som inte kan hanteras.

2.1.3 Rekommendationer

Samtliga aktörer behöver själva förhindra spridning av incidenter och minska konsekvenser av angrepp genom att placera informationssystem med olika funktioner i separata nätverkssegment i sin produktionsmiljö.

2.2 Filtrering av nätverkstrafik

Syftet med att filtrera nätverkstrafik är att förhindra spridning av incidenter och minska konsekvenser av angrepp.

2.2.1 Principer

[A] Nätverkstrafik filtreras mellan nätverkssegment i produktionsmiljöer.

2.2.2 Rekommendationer

Samtliga aktörer behöver själva filtrera nätverkstrafiken så att endast nödvändiga dataflöden förekommer mellan olika nätverkssegment.

2.3 Behörigheter, digitala identiteter och autentisering

Syftet med hantering av behörigheter är att säkerställa att endast behöriga användare och informationssystem har åtkomst till it-miljöer och att varje digital identitet inte har mer åtkomst till information och informationssystem än vad den behöver.

2.3.1 Principer

[A] En digital identitet kopplas till en individ, organisation, funktion, eller tjänst.

[B] Digitala identiteter och behörigheter som ger tillgång till externt åtkomliga informationssystem samt utvecklings-, test- och utbildningsmiljö hanteras i olika kataloger skilda från kataloger för produktionsmiljön.

[C] Digitala identiteter som ger systemadministrativ behörighet tilldelas restriktivt.

[D] För identifiering av individer används flerfaktorsautentisering (sk stark autentisering).

[E] Hantering av autentiseringsuppgifter utförs enligt interna regler.

2.3.2 Rekommendationer enligt MSBFS2020:7, 4.3 §:

Behörighetshanteringen bör genom interna regler säkerställa att:

1. digitala identiteter i produktionsmiljön är unika,
2. digitala identiteter och behörigheter är godkända innan de kopplas till en användare eller ett informationssystem,
3. tilldelade behörigheter är tidsbegränsade och kontrolleras en gång per år,
4. behovet av att använda olika kataloger för digitala identiteter och behörigheter är identifierat och hanterat, och
5. olika digitala identiteter används vid åtkomst till utvecklings- och testmiljö respektive produktionsmiljö.

2.3.3 Rekommendationer enligt MSBFS2020:7, 4.4 §:

Digitala identiteter som ger systemadministrativ behörighet bör endast användas för systemadministration och tilldelas restriktivt.

En digital identitet med systemadministrativ behörighet bör endast ges åtkomst till en begränsad del av produktionsmiljön.

2.3.4 Rekommendationer enligt MSBFS2020:7, 4.5 §:

Flerfaktorsautentisering bör användas vid

1. egen och inhyrd personals åtkomst till produktionsmiljön via externt nätverk,
2. systemadministrativ åtkomst till informationssystem, och
3. åtkomst till informationssystem som behandlar information som bedömts ha behov av utökat skydd.

2.3.5 Rekommendationer enligt MSBFS2020:7, 4.6 §:

Aktörer bör ha interna regler för hantering av autentiseringsuppgifter med krav på

1. längd och komplexitet,
2. när byte ska ske,
3. hur distribution ska ske, och
4. hur autentiseringsuppgifterna ska skyddas.

Tekniska system bör användas för att stödja efterlevnaden av reglerna avseende längd, komplexitet och byte.

2.3.6 Rekommendationer

Samtliga aktörer behöver själva säkerställa att endast behöriga användare och informationssystem inte har mer åtkomst till IT-system, informationssystem, och information än vad den behöver.

Samtliga aktörer behöver själva ha interna regler för behörighetshantering.

Samtliga aktörer behöver själva säkerställa att behörighetshantering utformas på ett sådant sätt att varje digital identitet inte har mer åtkomst till IT-system, informationssystem, och information än vad den behöver.

Samtliga aktörer behöver själva säkerställa att endast behöriga personer har åtkomst via stark autentisering med hjälp av flerfaktorsautentisering till de IT-system, informationssystem, och information som den behöver i produktionsmiljö.

2.4 Kryptering och nyckelhantering

Syftet med hantering av digitala nycklar och kryptering är att skydda information mot obehörig åtkomst och obehörig förändring vid användning, överföring och lagring.

2.4.1 Principer

[A] För att skydda information mot obehörig åtkomst och obehörig förändring vid användning, överföring och lagring används kryptering.

[B] Digitala nycklar hanteras på ett säkert sätt enligt interna regler.

[C] Säkra algoritmer såsom statistiskt säkerställd slumptalsgenerering används vid skapande av digitala nycklar.

2.4.2 Rekommendationer enligt MSBFS2020:7, 4.7 §:

Aktörer bör använda kryptering för att skydda

1. säkerhetsloggar mot obehörig åtkomst och obehörig förändring,
2. autentiseringsuppgifter mot obehörig åtkomst och obehörig förändring, och
3. information i behov av utökat skydd mot obehörig åtkomst och obehörig förändring vid överföring till informationssystem utanför myndighetens kontroll.

2.4.3 Rekommendationer enligt MSBFS2020:7, 4.9 §:

Aktörer bör ha interna regler för hantering av kryptering och hantering av digitala nycklar med krav på

1. hantering av krypteringsnycklar,
2. godkännande och förvaltning av krypteringslösningar, och
3. hur krypteringsalgoritmer, krypteringsprotokoll och nyckellängder ska väljas.

2.4.4 Rekommendationer

Samtliga aktörer behöver själva identifiera behov av kryptering för att skydda information mot obehörig åtkomst och obehörig förändring vid överföring och lagring.

Samtliga aktörer behöver själva hantera behovet och användning av kryptering och digitala nycklar.

Samtliga aktörer behöver själva ha interna regler för hantering med skydd av digitala nycklar under hela livscykel inklusive generering, lagring, arkivering, hämtning, distribution, återkallande och destruering av nycklar.

Samtliga aktörer behöver själva använda säkra algoritmer såsom statistiskt säkerställd slumptalsgenerering för skapande av digitala nycklar

2.5 Säkerhetskonfigurering

Syftet med säkerhetskonfigurering är att skydda IT-system och informationssystem mot obehörig åtkomst.

2.5.1 Principer

[A] IT-system och Informationssystem skyddas mot obehörig åtkomst genom att upprätthålla säker konfigurering.

[B] Utvecklings-, test- och driftmiljöer är separerade för att minska risken för obehörig åtkomst eller ändringar i driftmiljön.

2.5.2 Rekommendationer enligt MSBFS2020:7, 4.10 §:

Aktörer bör, för att skydda IT-system och informationssystem mot obehörig åtkomst genom att

1. byta ut förinställda autentiseringsuppgifter,
2. stänga av, ta bort eller blockera systemfunktioner som inte behövs, och
3. i övrigt anpassa konfigurationer för att uppnå avsedd säkerhet.

2.5.2 Rekommendationer

Samtliga aktörer behöver själva genom säker konfigurering av IT-system och informationssystem i produktionsmiljön skydda mot obehörig åtkomst.

2.6 Säkerhetstester och granskningar

Syftet med säkerhetstester och granskningar är att skapa en grund för identifiering av sårbarheter och risker i IT-system och information system.

2.6.1 Principer

[A] Sårbarheter och risker i IT-system och information system identifieras genom säkerhetstester och granskningar.

2.6.2 Rekommendationer enligt MSBFS2020:7, 4.12:

Aktörer bör ha interna regler för hur kontroll görs av att

1. informationssystemen är uppdaterade,
2. valda säkerhetsåtgärder är införda på korrekt sätt, och
3. genomförda säkerhetskonfigurationer är tillräckliga.

Automatiserade säkerhetstester och manuella granskningar bör kombineras vid kontroll av säkerheten i informationssystemen.

2.6.3 Rekommendationer

Samtliga aktörer behöver själva säkerställa att säkerhetstester och granskningar utförs för att identifiera av sårbarheter och risker.

2.7 Ändringshantering

Syftet med hantering av ändringar är att säkerställa att förändringar, uppgraderingar och uppdateringar i IT-system och informationssystem genomförs på ett strukturerat, spårbart och säkert sätt.

2.7.1 Principer

[A] Strukturerad och spårbar ändringshantering säkerställer att förändringar, uppgraderingar och uppdateringar i IT-system och informationssystem genomförs på ett säkert sätt.

2.7.2 Rekommendationer enligt MSBFS2020:7, 4.12:

Aktörer bör säkerställa att förändringar i IT-system och informationssystem genomförs på ett strukturerat och spårbart sätt.

Aktörer bör ha interna regler för ändringshantering med krav på

1. vilka kriterier som ska användas för att godkänna hård- och mjukvara innan installation eller användning,
2. hur risker för incidenter och avvikelser i samband med förändring i produktionsmiljön ska identifieras och hanteras,
3. hur mjukvara, utan onödigt dröjsmål, ska uppdateras till senaste version,
4. hur utbyte eller uppgradering av hård- och mjukvara som inte längre uppdateras eller stöds av leverantören ska säkerställas utan onödigt dröjsmål, och
5. hur risker ska hanteras när uppdatering eller uppgradering enligt punkt 3 och 4 inte kan genomföras.

Säkerhetsuppdateringar bör införas skyndsamt och behovet av att automatisera uppdateringar bör övervägas.

För att undvika störning vid förändring bör aktörer genomföra tester och ta fram en plan för återställning innan förändringen genomförs.

De interna reglerna bör tydliggöra hur risker för incidenter och avvikelser i samband med förändringar i utvecklings-, test- och utbildningsmiljö identifieras och hanteras.

2.7.3 Rekommendationer

Samtliga aktörer behöver själva säkerställa att förändringar i informationssystem genomförs på ett strukturerat, spårbart och säkert sätt.

2.8 Robust och korrekt tid

Syftet med att använda robust och korrekt tid i miljöer är att säkerställa korrekt kommunikation av information och meddelanden, samt korrekta och jämförbara händelseloggar och spårbarhetskedjor.

2.8.1 Principer

[A] Robust och korrekt tid används i alla miljöer genom tillämpning av koordinerad universell tid, UTC(SP).

2.8.2 Rekommendationer enligt MSBFS2020:7, 4.13 §:

Aktörer bör använda tidstjänsten Swedish Distributed Time Service på www.ntp.se.

Behovet av att använda robust och korrekt tid spårbar till den svenska tillämpningen av koordinerad universell tid, UTC (SP) i utvecklings-, test- och utbildningsmiljö bör identifieras och hanteras

2.8.3 Rekommendationer

Samtliga aktörer behöver själva använda robust och korrekt tid spårbar till den svenska tillämpningen av koordinerad universell tid, UTC(SP), i sin produktionsmiljö.

Samtliga aktörer behöver själva kontinuerligt övervaka tidsynkroniseringen.

2.9 Säkerhetskopiering

Syftet med säkerhetskopiering är kunna återställa information som förlorats eller förvanskats.

2.9.1 Principer

[A] Säkerhetskopiering används för att kunna återställa information som förlorats eller förvanskats.

[B] Vid bedömning av säkerhetskopieringens omfattning och intervall omhändertas även programvara, konfiguration utöver information och allt hanteras som en helhet.

2.9.2 Rekommendationer enligt MSBFS2020:7, 4.13 §:

Aktörer bör

1. minst en gång per dygn säkerhetskopiera information som behövs för aktörens förmåga att utföra sitt uppdrag, och
2. minst två gånger per år, eller vid större förändringar av produktionsmiljön, verifiera förmågan att, inom för aktörens godtagbara tidsperiod, återställa information från säkerhetskopior.
3. Behovet av säkerhetskopiering och förmåga till återställning av information i utvecklings-, test- och utbildningsmiljö bör identifieras och hanteras separat av varje enskild aktör.

2.9.3 Rekommendationer

Samtliga aktörer behöver själva regelbundet säkerhetskopiera sin information för att kunna återställa information som förlorats eller förvanskats.

Samtliga aktörer behöver själva förvara säkerhetskopior skilda från produktionsmiljön och skyddas mot skada, obehörig åtkomst och obehörig förändring.

2.10 Säkerhetsloggning och tillhörande analys

Syftet med säkerhetsloggning är att säkerställa spårbarhet i Informationssystem och IT-system som kan användas för analys, uppföljning och hantering av fel, avvikelser samt incidenter.

2.10.1 Principer

[A] Loggning av säkerhetsrelaterade händelser tillämpas regelbundet enligt interna rutiner.

[B] Analys av säkerhetsloggar används för att kontinuerlig upptäcka och hantera incidenter och avvikelser samt fel.

2.10.2 Rekommendationer enligt MSBFS2020:7, 4.16 §:

Aktörer bör för att säkerställa spårbarhet i informationssystem, logga minst följande säkerhetsrelaterade händelse enligt interna rutiner:

1. Obehörig åtkomst och försök till obehörig åtkomst till IT-system och informationssystem.
2. Förändringar av konfigurationer och säkerhetsfunktioner som förutsätter priviligierade rättigheter.
3. Förändringar av behörighet för användare och informationssystem.

2.10.3 Rekommendationer enligt MSBFS2020:7,4. 17 §:

Aktörer bör analysera innehållet i loggarna för att upptäcka och hantera incidenter och avvikelser enligt interna rutiner. Loggarna kan

1. möjliggöra utredning av intrång, tekniska fel och brister i säkerheten,
2. utformas på ett sätt som möjliggör jämförbarhet mellan olika loggar, och
3. vara tillgängliga för analys under fastställd bevarandetid.
4. bör innehålla uppgift om vem eller vad som agerat, vad som har skett och vid vilken tidpunkt.
5. skapa jämförbarhet genom att använda koordinerad universell tid, UTC(SP) för samtliga säkerhetsloggar.
6. samlas i ett för ändamålet avsett informationssystem.

2.10.4 Rekommendationer

Samtliga aktörer behöver själva för att säkerställa spårbarhet i informationssystem och IT-systemen logga säkerhetsrelaterade händelser regelbundet.

Samtliga aktörer behöver själva enligt interna rutiner dokumentera hur tekniska säkerhetsloggarna används samt var loggningsuppgifter hämtas och lagras, hur de skyddas och hur länge de bevaras.

Samtliga aktörer behöver själva enligt interna rutiner skydda loggningsverktyg och logginformation mot manipulation och obehörig åtkomst.

Samtliga aktörer behöver själva regelbundet analysera innehållet i säkerhetsloggarna för att upptäcka och hantera incidenter och avvikelser.

2.11 Övervakning av nätverkstrafik

Syftet med övervakning av nätverkstrafik är att upptäcka och hantera incidenter och avvikelser.

2.11.1 Principer

[A] Berörd nätverkstrafik övervakas kontinuerligt.

2.11.2 Rekommendationer enligt MSBFS2020:7, 4.18 §:

- Behovet av intrångsdetektering och intrångsskydd bör bedömas för berörd nätverkstrafik och för aktörs produktionsmiljö i sin helhet.

- Behovet bör även bedömas för aktörs utvecklings- test- och utbildningsmiljö.

2.11.3 Rekommendationer

Samtliga aktörer behöver själva kontinuerligt övervaka berörd nätverkstrafik.

Samtliga aktörer behöver själva identifiera och hantera behovet av intrångsdetektering och intrångsskydd.

Samtliga aktörer behöver själva identifiera och hantera behovet av realtidsövervakning av nätverkstrafik.

2.12 Övervakning av IT-system och informationssystem

Syftet med övervakning av IT-system och informationssystem är att upptäcka och hantera incidenter och avvikelser.

2.12.1 Principer

[A] Berörda IT-system och informationssystem övervakas kontinuerligt.

2.12.2 Rekommendationer enligt MSBFS2020:7, 4.18 §:

- Behovet av intrångsdetektering och intrångsskydd bör bedömas för berörda IT-system och informationssystem och för aktörs produktionsmiljö i sin helhet.

Behovet bör även bedömas för aktörer utvecklings- test- och utbildningsmiljö.

2.12.3 Rekommendationer

Samtliga aktörer behöver själva kontinuerligt övervaka berörda IT-system och informationssystem.

Samtliga aktörer behöver själva identifiera och hantera behovet av realtidsövervakning av berörda IT-system och informationssystem.

2.13 Skydd mot skadlig kod

Syftet med skydd mot skadlig kod är att säkerställa att information och informations­system skyddas mot intrång, inkommande skadlig kod, och spridning av skadlig kod.

2.13.1 Principer

[A] Information och informations­system skyddas mot skadlig kod genom införande av upptäckande, förebyggande och återställande säkerhetsåtgärder.

[B] Användning av programvara som ger skydd mot skadlig kod.

2.13.2 Rekommendationer

Samtliga aktörer behöver själva ha ett uppdaterat eget skydd mot intrång, skydd mot inkommande skadlig kod samt skydd mot spridning av skadlig kod.

Samtliga aktörer behöver själva använda mjukvara som ger skydd mot skadlig kod. För informationssystem där sådan mjukvara inte finns tillgänglig behöver andra åtgärder vidtas som ger motsvarande skydd.

2.14 Skydd av utrustning

Syftet med skydd av utrustning är att förhindra förlust, skada, stöld, påverkan, eller obehörig åtkomst av den utrustning som informationssystem består av och hanterar information.

2.14.1 Principer

[A] Den utrustning som informationssystem består av och hanterar information skyddas mot förlust, skada, stöld, påverkan, eller obehörig åtkomst.

2.14.2 Rekommendationer

Samtliga aktörer behöver själva ha interna regler för hur utrustning skyddas.

Samtliga aktörer behöver själva skydda utrustning mot skador och obehörig åtkomst, genom att

1. placera utrustning i särskilda it-utrymmen,
2. tilldela behörighet till särskilda it-utrymmen restriktivt,
3. identifiera och hantera behovet av övervakning och larm i särskilda it-utrymmen,
4. registrera tillträde till särskilda it-utrymmen på individnivå,
5. placera och skydda utrustning för att minska riskerna för miljörelaterade hot och faror och möjligheter för obehörig åtkomst.

Lagringsmedia, informationssystem och IT-system behöver på ett säkert sätt avvecklas när de inte längre behövs med stöd av interna regler.

2.15 Redundans och återställning

Syftet med redundans och återställning är att säkerställa tillgänglighet till IT-system och informationssystem under och efter avvikelser eller incidenter enligt i förväg accepterad omfattning och servicenivåer.

2.15.1 Principer

[A] Tillgänglighet till IT-system och informationssystem vid avvikelser eller incidenter säkerställs genom tillräcklig redundans och förmåga till återställning.

2.15.2 Rekommendationer enligt MSBFS2020:7, 4.12, 4.22 §:

1. För att undvika störning vid förändring bör aktör genomföra tester och ta fram en plan för återställning innan förändringen genomförs.
2. Övning av återställning bör ske regelbundet och utifrån identifierat behov av tillgänglighet.

2.15.3 Rekommendationer

Samtliga aktörer behöver själv,

1. ha tillräcklig redundans och förmåga till återställning för att uppfylla krav på tillgänglighet vid avvikelser eller incidenter enligt i förväg accepterad omfattning och servicenivåer.
2. ha interna regler för återställning av produktionsmiljön i sin helhet och för enskilda IT-system och informationssystem,
3. öva återställning av informationssystem som är centrala för aktörens förmåga att utföra sitt uppdrag, och
4. placera centrala servrar och central nätverksutrustning som skapar redundant funktion i olika särskilda it-utrymmen.

2.16 Kontinuitet för IT-system och utrustning

Syftet med kontinuitet är att under och efter svåra situationer, incidenter och kriser kunna upprätthålla fungerande IT-system med utrustning och lagringsmedia enligt i förväg accepterad omfattning och servicenivåer.

2.16.1 Principer

[A]Förmågan att upprätthålla kontinuitet under och efter svåra situationer, incidenter och kriser fastställs, dokumenteras, införs, och kontinuerligt kontrolleras och utvärderas.

2.16.2 Rekommendationer

Samtliga aktörer behöver själva fastställa, dokumentera, införa, och kontinuerligt kontrollera och utvärdera förmågan att upprätthålla kontinuitet under svåra situationer, incidenter och kriser enligt i förväg accepterad omfattning och servicenivåer.