ISO 27001 och rikets säkerhet

Kan ISO 27001 användas för informationssäkerhet för hemliga uppgifter (rikets säkerhet)? Jag tror det. Fördelarna borde överväga, men frågan är inte helt okomplicerad.

Krav på ledningssystem för informationssäkerhet finns i den internationella standarden ISO/IEC 27001:2005. Standarden gäller som svensk standard och finns på engelska och i svensk översättning (SS-ISO/IEC 27001:2006). Den är en modell för att upprätta, införa, driva, övervaka, granska, underhålla och förbättra ett ledningssystem för informationssäkerhet.

Statliga myndigheter ska i sitt arbete att upprätthålla säkerhet i sin informationshantering bedriva arbetet i former enligt den svenska standarden.1 Alla myndigheter omfattas inte, t ex är Försvarsmakten undantagen.2 En myndighets arbete med informationssäkerhet behöver inte använda den svenska standarden om det finns andra bestämmelser om arbete med informationssäkerhet.3 Ett exempel på detta är verksamheter där det ska finnas ett säkerhetsskydd. Informationssäkerheten som en del av säkerhetsskyddet ska förebygga att uppgifter som omfattas av sekretess och som rör rikets säkerhet obehörigen röjs, ändras eller förstörs.4

En förklaring till att Försvarsmakten inte omfattas av kravet kan vara att det sedan lång tid redan finns ett etablerat säkerhetsarbete inom den militära säkerhetstjänsten. Men inget säkerhetsarbete är helt perfekt. Om standarden även tillämpas på informationssäkerhet för hemliga uppgifter (rikets säkerhet) tror jag det skulle bidra till ett stärkt säkerhetsskydd. Personer i och utanför Försvarsmakten skulle också lättare förstå varandra om informationssäkerhetsarbete genomförs på det sätt som standarden beskriver.

En myndighet som redan har ett ledningssystem för informationssäkerhet enligt standarden skulle lättare kunna leda informationssäkerheten för hemliga uppgifter (rikets säkerhet). Att ha flera ledningssystem som hanteras på olika sätt för olika slag av uppgifter tror jag inte på. Ett sammanhållet ledningssystem för alla informationstillgångar inom en organisation måste vara att föredra.

Det finns inget som hindrar en organisation att använda standarden för hemliga uppgifter (rikets säkerhet). Skyddsåtgärderna för sådana uppgifter är mer långtgående och mer omfattande än för andra slag av uppgifter. Ett sammanhållet ledningssystem för en organisations informationssäkerhet måste tydligt peka ut vilket slag av informationstillgång som en viss skyddsåtgärd är avsedd för, så att man inte får ett överskydd för uppgifter som inte rör rikets säkerhet.

Bilaga A är undermålig för att skydda mot spioneri

I bilaga A till standarden finns en lista med åtgärdsmål och säkerhetsåtgärder som en organisation ska välja ur när organisationen skapar ett ledningssystem för informationssäkerhet.5 För informationssäkerhet till skydd för hemliga uppgifter (rikets säkerhet) är bilaga A undermålig. Skyddsåtgärderna är inte tillräckliga för kunna ge ett tillräckligt skydd mot andra staters underrättelseinhämtning eller en insider som går främmande makt tillhanda.

Bilaga A har ett tydligt fokus på IT-system. Informationssäkerhet behöver även finnas för information utanför IT-system, t ex muntlig information och pappershandlingar.

Åtgärdsmål och säkerhetsåtgärder för skydd av hemliga uppgifter

Andra åtgärdsmål och säkerhetsåtgärder än de som finns i bilaga A får användas i ett ledningssystem för informationssäkerhet.6 En idé som jag har är att expertmyndigheterna tar fram en komplettering till bilaga A med åtgärdsmål och säkerhetsåtgärder som avser säkerhetsskydd för hemliga uppgifter (rikets säkerhet). Dessa struktureras om möjligt på samma sätt som mål och åtgärder i bilaga A. En myndighet kan sedan i sitt informationssäkerhetsarbete använda denna kompletterande lista för att definiera sitt skydd för sådana uppgifter.

Enligt standarden ska den organisation som utelämnar åtgärdsmål och säkerhetsåtgärder i bilaga A motivera utelämnandet.7 På samma sätt skulle man kunna hantera den kompletterande listan med åtgärdsmål och säkerhetsåtgärder. Ett exempel på relevanta utelämnanden är säkerhetsåtgärder som rör handlingar som är placerade i informationssäkerhetsklass HEMLIG/TOP SECRET. Om en organisation inte har sådana handlingar, och inte kan förutsättas ta emot sådana handlingar, behöver organisationen i sitt ledningssystem för informationssäkerhet inte ta upp skyddsåtgärder för H/TS-handlingar.

När Försvarsmakten och Säkerhetspolisen genomför tillsyn av säkerhetsskyddet kan bl a val av åtgärdsmål och säkerhetsåtgärder granskas. Om den granskade organisationen har utelämnat sådana säkerhetsåtgärder som tillsynsmyndigheten menar inte får utelämnas behöver organisationen förbättra sitt ledningssystem.

Denna kompletterande lista skulle också kunna användas vid säkerhetsskyddad upphandling (SUA) där säkerhetsskyddet mellan beställande myndighet och utförande företag regleras i ett säkerhetsskyddsavtal. Ett företag som tillämpar standarden borde ha lättare att känna igen strukturen och kunna ta till sig krav på informationssäkerhet.

Frågor, frågor, frågor

Om standarden ska användas för informationssäkerhet för hemliga uppgifter (rikets säkerhet) väcker det frågan om hur detta ska styras. Säkerhetsskydd regleras i dag med bindande rättsregler. Att använda standarden får inte medföra att regleringen blir svagare. En annan fråga är hur signalskydd, som är en del av informationssäkerheten, kan inordnas. Det finns säkert fler aspekter som jag inte har tänkt på.

/Kim Hakkarainen

Blogginlägget innehåller hänvisningar till bestämmelser eller andra källor som inte längre gäller. Även om de har ersatts kan påståenden och slutsatser fortfarande vara giltiga.

  1. 4-6 §§ Myndigheten för samhällsskydd och beredskaps föreskrifter (MSBFS 2009:10) om statliga myndigheters informationssäkerhet. ↩︎

  2. 2 § Myndigheten för samhällsskydd och beredskaps föreskrifter (MSBFS 2009:10) om statliga myndigheters informationssäkerhet. ↩︎

  3. 3 § Myndigheten för samhällsskydd och beredskaps föreskrifter (MSBFS 2009:10) om statliga myndigheters informationssäkerhet. ↩︎

  4. 7 § 1 säkerhetsskyddslagen. ↩︎

  5. 4.2.1 g) i ISO/IEC 27001:2006. ↩︎

  6.  4.2.1 g) i ISO/IEC 27001:2006. ↩︎

  7.  4.2.1 j) 3) i ISO/IEC 27001:2006. ↩︎