Skip to content

Sammenhengen mellom forskjellige rammeverk

Dette blogginnlegget handler om presentasjonen Jan Bjørnsen og Martin Berg Nilsen holdt på Sikkerhetsfestivalen 2024. De tok deg igjennom sammenhengen mellom ulike:  

  • Rammeverk (IT-sikkerhetsrammeverk, IT driftsrammeverk og IT Forvaltningsrammever) 
  • Lover som berører IT (GDPR, SOX, DORA og NIS2) 
  • og Standarder man kan sertifiseres mot (ISO, CIS, TISAX, NIST) 

Her fokuserte de på å illustrere at det finnes områder hvor lover, rammeverk og standarder overlapper. Men hva betyr dette for deg som jobber med etterlevelse av disse? Det får du svar på i dette blogginnlegget. 

 

De aller fleste har et forhold til GDPR, og kanskje spesielt de som leser dette innlegget. GDPR stiller en rekke krav rundt behandling av personvern og mange husker nok hvor mye arbeid og innsats som krevdes for å forsikre etterlevelse av denne lovgivningen. Derfor er det kanskje ikke så rart at man kan føle seg litt overveldet når man ser på utviklingen av nye lovgivninger som er på linje med GDPR, både i form av omfang, men også når det gjelder sanksjoner. De fleste finner bøter opp til 4% av total omsetning ubehagelig. 

 

Hvis man antar at organisasjonen lever etter kravene GDPR stiller vil man ha et godt grunnlag å jobbe ut ifra. På bildet forsøker vi å illustrere hvordan andre lover og standarder overlapper med GDPR. Vi har brukt TISAX, som er en standard for informasjonssikkerhet innen bilindustri, og SOX, som er en Amerikansk lovgivning for finansiell rapportering og internkontroll, for å vise at her er det områder som overlapper. Det kan selvfølgelig legges på flere andre lover og reguleringer som på samme måte stiller krav til informasjonssikkerhet og trygg IT drift. 


A close-up of several colored ovals

Description automatically generated

 

Når vi sier at det er overlappende områder mener vi at her finnes felles kontrollaktiviteter og tiltak som kan iverksettes. Den største forskjellen er hva slags type data de forskjellige lovene fokuserer på. GDPR på personopplysninger, SOX på finansiell informasjon osv. Disse felles kontrollaktivitetene som vi beskriver i de valgte rammeverkene, oppfyller krav fra flere lovgivninger og standarder. Det betyr at dersom man er klar over de overlappende områdene vil man kunne gjenbruke allerede implementerte tiltak og dokumentasjonen for å oppfylle flere krav. Dette kaller vi gjerne på nynorsk for "IT General Controls"(ITGC). 

 

Bildene under vil illustrere dette. A diagram of a company

Description automatically generated

I bildet over kan vi se at områder fra rammeverkene ITIL, COBIT5 og NIST CSF v2 overlapper med hverandre. 

(NB: Vi har også tatt med ISO 27001/27002:2013 og NIST CSF v1.1 da disse gjerne ble brukt inntil ganske nylig som sikkerhetsrammeverk. Nå har NIST CSF v2 blitt den nye de facto rammeverket for informasjonssikkerhet og ISO 27001:2022 er oppfattet som en ren standard).  

Noe som kanskje ikke kommer så tydelig frem er at de forskjellige rammeverkene har hver sine fokusområder.  

  • COBIT for “IT Styring og kontroll” og for “IT Forvaltning” (Governance of Enterprise IT, IT Governance) 
  • ITIL for “IT Drift” (IT Operations) 
  • NIST CSF v2 for “Informasjonssikkerhet og kontroll” (Information Security & Control) 

Derfor mener vi at en kombinasjon av disse vil gi en bedre og mer helhetlig håndtering av alt fra topp til bunn, fra IT Styring og kontroll til informasjonssikkerhet. Dersom man kun baserer seg på et av disse rammeverkene kan det være områder som enten ikke dekkes i det hele tatt, eller områder hvor man ikke har så gode kontroller på plass.  

 A diagram of a company's company's company's company's company's company's company's company's company's company's company's company'

Description automatically generated

Dette bildet viser hvordan det kan se ut når vi legger sammen alle lagene i denne illustrasjonen. Det blir enda et lag med kompleksitet når man i tillegg skal ivareta krav fra kommende lovgivninger som for eksempel NIS2 og DORA. Dette kan virke rotete og uoversiktlig ut, men når det er brutt ned i mindre, og mer lesbare, figurer ser man fort sammenhengen og de overlappende områdene. 

 

Ut ifra denne modellen og vår virkelighetsforståelse begynte vi å kryss-referere kontrollaktiviteter beskrevet i rammeverkene og krav fra de forskjellige lovgivningene og standardene mot hverandre. Heldigvis finnes det gode kilder til eksisterende kryssreferanser. Vår erfaring er at NIST, CIS og ISACA har gode dokumenter som i kombinasjon vil gi en god oversikt over hvilke kontroller og tiltak som kan gjenbrukes. 

 

Det er dessverre slik at det ikke alltid er et en-til-en-forhold mellom de forskjellige rammeverkene, lovgivningene og standardene, så det vil kreve litt innsats for å få en helhetlig oversikt. Gevinsten av å investere tid og energi i denne kartleggingen vil være at man fort kan gjenkjenne krav og iverksette kontroller og tiltak som dekker flere krav. Og sett fra en annen vinkel: Når kravet er forstått kan vi lett finne fram til hvilken policy, prosedyre, retningslinje eller arbeidsinstruks som vi kan referere til som beskriver hvordan vi utfører den/de aktuelle kontrollen(e). I tillegg kan vi bygge opp et bibliotek (“repository”) som er vårt revisjonsspor på at vi faktisk jobber slik dokumentene beskriver. 

 

For å runde av blogginnlegget vil jeg beskrive hvordan vi systematisk jobber igjennom prosedyre- og strategidokumenter år etter år. Vi ønsker å understreke at dette krever kontinuerlig vedlikehold og skal være en del av de årlige oppgavene for vedlikehold av rammeverkene, noe som også er et krav i forskjellige lover og standarder.  

 

Vår erfaring med å etablere dokumentene og presentere dem i et styringssystem (ISMS for informasjonssikkerhet og et ITGMS (IT Governance Management System)) trenger flere versjoner for å modnes i en virksomhet. Gjerne 4 eller flere versjoner. 

  • Versjon 1 av prosedyredokumenter vil være veldig generiske. Vårt mål er å starte med å legge så lite restriksjoner som mulig på de ansatte, men samtidig opprettholde kravene som stilles. Vi ønsker å være praktiske og pragmatiske med implementasjonen, og heller jobbe med å gjøre små justeringer etter hvert som dokumentene etableres i organisasjonen. 
  • Versjon 2 blir mer spisset mot organisasjonen, men vil fortsatt være relativt generiske.  
  • Versjon 3 blir enda mer spisset, og her må vi begynne å vurdere om de er for stringente. Målet er å ende opp med et sett med balanserte dokumenter som ivaretar informasjonssikkerheten og dokumentasjonskravene, men samtidig tilrettelegger for at de ansatte kan gjennomføre jobben sin uten å føle at de må hoppe igjennom utallige ringer.  
  • Versjon 4 vil altså være den balanserte og mest tilpassede versjonen.  

 

Vi jobber på samme måte med strategidokumenter, hvor vi lager et dokument per sikkerhetsområde/funksjon. Versjon 1 fokuserer vi på "Quick Wins", altså hvilke områder kan vi kjapt iverksette enkle tiltak for å oppfylle krav som stilles. Versjon 2 jobber vi med de tiltakene som er enkle å iverksette, men som kanskje krever litt mer tid for å få på plass. Versjon 3 dreier seg om å ivareta de rammekravene som kanskje har blitt nedprioritert i de forrige versjonene, og versjon 4 vil da være en repetitiv og kontinuerlig vurdering av den nå-værende strategien for å se at alle målene er ivaretatt. 

 

Dersom du har noen spørsmål, eller ønsker å diskutere dette på et vis, kan du kontakte Jan eller Martin via epost. Vi tar gjerne en diskusjon med deg! 

Kontakt oss via Martin.berg-nilsen@knowit.no og/eller Jan.bjornsen@knowit.no.