Precis som med ett körkort…

Att vara certifierat inom ISO 27001 har länge varit en gyllene grund för en organisation att stå på och visa att man inte bara tar frågan på allvar utan att man dessutom låter sig granskas av en extern revisor och därmed har full koll. Men tyvärr räcker det inte riktigt – jag brukar jämföra ett ISO 27001 certifikat med ett körkort. Som bekant sköter du dig under uppkörningen, men så snart du har lappen i hand finns det inga hinder att vare sig köra för fort, strunta i stopplikt eller fippla med mobilen medan du kör. Blir du påkommen kan det göra ont, du kanske får böter eller i värsta fall får körkortet återkallat ett tag – men ärligt talat är risken inte särskilt stor.

I en certifieringsprocess för ISO 27001 så kan en revisor omöjligen granska efterlevnaden av allt i ledningssystemet som certifieringen kräver, än mindre verifiera efterlevnad. Och även en erfaren revisor med skinn på näsan kan luras runt frågor under en revision.

Hur ska man då göra om man vill provtrycka en presumtiv leverantör? Här kommer några tips och idéer!

Begär in SoA:n

Sedan flera år rekommenderar flera, inte minst MSB i sin publikation Upphandla Informationssäkert att den som upphandlar ska begära in leverantörens SoA, eller Uttalande om Tillämplighet (UoT), och granska detta. Det är i det dokumentet det bland annat ska framgå vilka av säkerhetskontrollerna i ISO 27001 Bilaga A som leverantören valt att utesluta ur sin certifiering och därmed externa granskning och varför. Det kan vara svårt att själv granska ett sådant dokument, men väl värt att ta hjälp med detta i en utvärdering.

Alla leverantörer ska kunna delge sin SoA, även i offentlig upphandling då dokumentet blir en inkommen handling – det ska helt enkelt inte finnas några hemligheter där.

Begär att få tillgång till senaste revisionsrapporten

Som en del i leverantörsutvärdering är det värt att fråga efter senaste revisionsrapporten inklusive lista på funna avvikelser. Det är dock inte säkert att en leverantör kan eller vill skicka in den i offentlig upphandling men kan kanske ge tillgång till dokumenten på annat vis under upphandlingsprocessen.

Efterfråga SOC 2 Type 2 rapport

En organisation som tar informationssäkerhetsfrågan på allvar har beställt en revision och rapport enligt SOC 2 Type 2. Till skillnad mot en ISO 27001 revision är en SOC 2 Type 2 mer djupgående och dessutom följs processer och efterlevande upp över tid och ger därmed en bild av hur en organisation upprätthåller kontinuitet inom informationssäkerhetsområdet.

Även här finns uppenbar risk att en organisation väljer att inte skicka in sin rapport i en offentlig upphandling i och med risken att den ska kunna begäras ut men samma sak här – begär i så fall att få tillgång till den på annat vis, till exempel få den förevisad i lämpligt forum.

Och naturligtvis koll på kraven

Det spelar egentligen ingen roll hur många olika dokument som en leverantör skickar in för att styrka hur man arbetar med säkerhet om inte ni som upphandlar har koll på era interna och externa krav som ni måste kunna leva upp till. En leverantörs informationssäkerhetsarbete är i praktiken bara en förlängning av ert eget så det ni behöver göra är att mappa era krav och se vilka som en leverantör blir en del av. Det är först då som ni på riktigt kan granska och utvärdera en leverantör utifrån ett informationssäkerhetsperspektiv.

Inlägget Räcker ett ISO 27001 certifikat i upphandling? dök först upp på Matte.Nu.

Förändringarna i korthet

Här är en summering av förändringarna i 2022 års utgåva jämfört med den gamla:

• 114 säkerhetsåtgärder är nu 93
• Säkerhetsåtgärderna är uppdelade i Organisatoriska, Personella, Tekniska och Fysiska.
• Elva säkerhetsåtgärder är helt nya
• Ett sextiotal åtgärder från den gamla har slagits samman i den nya versionen
• ”Mål” har blivit ”Syfte”
• Man har tillfört attribut till säkerhetsåtgärderna

Avsnittsindelning

I tidigare version spretade det väldigt mycket – de organisatoriska säkerhetsåtgärderna hittade man i många av avsnitten, samma sak med tekniska medan personella och fysiska varit mer samlade. Nu ligger de samlade:

5. Organisatoriska säkerhetsåtgärder (37 st)
6. Personella säkerhetsåtgärder (8 st)
7. Fysiska säkerhetsåtgärder (14 st)
8. Tekniska säkerhetsåtgärder (34 st)

Det är alltså även fortsatt störst fokus på det organisatoriska tätt följt av det tekniska i informationssäkerhetsarbetet vilket är logiskt och väl återspeglar verkligheten i vardagen. Avsnittsindelningen gör det mycket enklare att komma igång med ISO 27002 (och därmed i förlängningen också med ISO 27001) i och med att det inte är så splittrat.

Attribut

En nyhet värd att utveckla mer är att det nu finns attribut kopplade till säkerhetsåtgärderna i form av #taggar. En säkerhetsåtgärd taggas exempelvis som förebyggande, detektiv eller korrigerande enskilt eller i kombination. Syftet är att man ska få förståelse för i vilket kontext man inför en åtgärd.

Mål och syfte

I tidigare version tog standarden upp målet med införandet av en säkerhetsåtgärd – nu är det ersatt med syfte. Även detta en välkommen förändring i mitt tycke eftersom det inte ska handla om att uppfylla mål när man inför säkerhetsåtgärder utan det ska ha ett tydligt syfte.

Komma vidare

Själva grunden är densamma som tidigare i att det är organisationens risker som ska ligga bakom val av säkerhetsåtgärder och implementationer. Även om informationssäkerhetsriskerna ska gås igenom med regelbundenhet så är det inte nödvändigt i samband med de justeringar som krävs för linjering mot nya ISO 27002.

Den svenska översättningen beräknas publiceras redan under andra kvartalet 2022, och här beräknas också en uppdaterad version av ISO 27001 publiceras. Här handlar det framför allt om en uppdaterad Bilaga A som är linjerad mot nu gällande version av ISO 27002.

• Om organisationen redan har ett implementerat LIS byggt på den gamla versionen behöver ni snarast komma igång med linjering mot den nya versionen. Som hjälp finns bilaga B i 2022 års version av standarden för mappning mellan versionerna. Utöver det kommer det krävas att ni utvärderar de elva nya kontrollerna och planerar för implementation av dessa.
• Är ni certifierade mot ISO 27001 har ni en övergångsperiod att uppdatera ledningssystemet, normalt är övergångsperioden två år när det kommer nya versioner av standarder.
• Om ni håller på att bygga upp och implementera ett LIS är det klokt att redan nu se över vilka justeringar som behöver göras för att det ska stämma överens med nu gällande version – trots allt så har den nya versionen ersatt den gamla.

Och inte minst – det är aldrig en dålig idé att ta hjälp i såväl arbetet med att analysera gapen mellan ett befintligt LIS och nya versionen av standarden som att ta fram en handlingsplan.

Inlägget Ny ISO/IEC 27002 – hur komma vidare? dök först upp på Matte.Nu.

Så vad betyder det i praktiken?

Bilaga A och dess 114 säkerhetsåtgärder (i 2013 års version) är i praktiken ska-krav. Det vill säga, organisationen ska förhålla sig till åtgärderna i bilagan på ett eller annat sätt:

1. Uteslutning – ”åtgärden berör inte oss”.
   Om en åtgärd helt uppenbart inte berör organisationen utesluter man den. Man berättar i en motivering i sitt uttalande om tillämplighet varför man anser att den inte är tillämplig. Exempelvis, om ni inte utvecklas mjukvara är det mesta i A.14.2 inte aktuellt. För de flesta är det aktuellt med vissa uteslutningar, men revisorn kommer utmana samtliga av dem och dess motiveringar.
   
2. Implementerad:
   Om en åtgärd inte kan eller bör uteslutas så behöver den implementeras. I de flesta organisationer som arbetat några år med IT-säkerhet i praktiken har normalt infört många åtgärder redan. Berätta hur.
   
3. Att implementera (handlingsplan):
   Åtgärder som inte kan/bör uteslutas ska implementeras om det ännu inte är gjort. Berätta i uttalandet att det ska implementeras, status, ansvarig och när det förväntas vara klart.

Slutsats

Bilaga A och dess 114 åtgärder är ska-krav, men det innebär alltså inte nödvändigtvis att åtgärderna ska vara implementerade. Det är helt okej att ha en handlingsplan för sådant som ännu inte är klart. Ta hjälp med att utveckla ett uttalande om tillämplighet som fungerar för just din organisation – det finns många exempel på Internet men det är trots allt komplicerat att få till det på ett bra sätt. Ta också gärna hjälp med att bedöma vilka säkerhetsåtgärder som är tillämpningsbara för just er.

Inlägget Ska-krav i ISO 27001 bilaga A? dök först upp på Matte.Nu.

Den nuvarande versionen av ISO 27001 släpptes under 2013, då var certifiering inom informationssäkerhet på nära nog var mans läppar inom IT-branchen. I början var det få som var certifierade och de som var det tillskrevs närmast magiska egenskaper. Men under åren som gått så har värdet av en certifiering devalverats gradvis för att idag mest motsvara ett körkort. Det är en hygienfaktor i de fall organisationen till exempel levererar IT-tjänster till företag och organisationer.

Det kan finnas en uppsjö av anledningar till att arbeta strukturerat med informationssäkerhet enligt ISO 27001. Din organisation kanske levererar IT-tjänster till andra organisationer? Kanske utvecklar ni system eller programvara där personuppgifter eller annan känslig information hanteras? Eller så har ni i organisationen hand om personuppgifter, kanske rentav känsliga också? Eller, inte minst, hanterar era egna företagshemligheter som det skulle vara katastrof om de kom på avvägar? Kort sagt, jag är övertygad om att de allra flesta organisationer skulle må bra av att arbeta strukturerat med informationssäkerhet.

Men certifiera sig?

Att certifiera sig mot ISO 27001 är i regel inte lätt. Det kommer att ta tid, vara dyrt, kräva ett sjuhelsikes engagemang och kosta en hel del pengar. Är det värt det? Det kan bara ni själva avgöra. Mitt råd är alltid att vänta med certifiering så länge som det bara går, men så snart det bara går påbörja arbetet att arbeta med inspiration av ISO 27001. De flesta IT-upphandlande organisationer har lärt sig att en leverantörs certifiering inte säger någonting om den faktiska säkerheten. På samma sätt som att just ett körkort inte säger någonting om hur innehavaren faktiskt framför sitt fordon en vanlig dag. Det går alldeles utmärkt att ha en tung högerfot och att strunta att stanna vid en stoppskylt – ända tills dess att polisen kommer på en.

Det står klart att man behöver mer än bara ett certifikat för att bevisa sig, exempel på åtgärder som jag oftare och oftare ser krav på är:

• Uttalande om hur man förhåller sig till andra ramverk, så som NIST SP 800-53 och CIS Controls.
• SOC 2 Type 2 rapport.

I körkortsjämförelsen skulle det handla om att tvinga bevisa sin körduglighet, och hur skulle det gå till? En SOC-2 Type 2 rapport innebär att en extern revisor gör minst två revisioner med minst sex månaders mellanrum. På så sätt kan revisorn inte bara se att man gör så som man utger sig för att göra, utan kan även se att man faktiskt fortsätter att göra det.

För att summera

Alla företag och organisationer hanterar information. Och sedan dataskyddsförordningen (GDPR) trädde i kraft hanterar dessutom de flesta organisationen information som faktiskt behöver skyddas enligt lag. Personuppgifter hanterar man bara genom att hantera anställda och kontakter hos sina kunder. Idag är dessutom immateriella tillgångar ofta en stor del av ett företags värde.

ISO 27001 är absolut den standard att arbeta med inspiration från. Inte nödvändigtvis helt enligt, men låt åtminstone inte arbetet med informationssäkerhet gå stick i stäv med standarden. Ta hjälp för att lägga upp en plan för att kunna dra bäst nytta av standarden. Information är och förblir en av er organisations viktigaste tillgångar. Ta väl hand om den!

Inlägget Certifiera inom ISO 27001? dök först upp på Matte.Nu.