Hvad er et ISMS? Forbind sikkerhedsarbejdet med forretningsbeslutninger

Sikkerhedsarbejde kan se travlt ud uden at være koordineret. Udviklingsafdelingen patcher systemer, HR håndterer fratrædelser, indkøb gennemgår leverandører, og ledelsen godkender undtagelser. Et ledelsessystem for informationssikkerhed forbinder disse aktiviteter med fælles mål og en eksplicit beslutningsproces.

For en administrerende direktør er det vigtige spørgsmål ikke, om virksomheden har nok sikkerhedsdokumenter. Det er, om ledelsen kan forklare, hvad der skal beskyttes, hvilke risici der betyder noget, hvem der er ansvarlig, og hvorfor det nuværende beskyttelsesniveau er acceptabelt. Et ISMS gør disse svar gentagelige, efterhånden som virksomheden ændrer sig.

Hvad et ISMS faktisk styrer

Et ledelsessystem for informationssikkerhed er det organisatoriske system til styring af informationssikkerhedsrisici. Det omfatter ansvarsområder, politikker, processer, ressourcer, kontroller og evaluering. Software kan understøtte det, men softwaren er ikke systemet. Et dokumentbibliotek kan beskrive det, men dokumenter alene viser ikke, at det fungerer.

Formålet er at beskytte tre egenskaber ved information:

• Fortrolighed: Oplysningerne er kun tilgængelige for autoriserede personer og systemer.
• Integritet: Oplysningerne forbliver korrekte, fuldstændige og beskyttet mod uhensigtsmæssig ændring.
• Tilgængelighed: Autoriserede brugere kan få adgang til oplysningerne og bruge de understøttende tjenester, når der er behov for det.

Disse egenskaber omsættes til forretningsmæssige bekymringer. Eksponerede kunderegistreringer kan undergrave tilliden og skabe retlige forpligtelser. Forkerte betalingsinstruktioner kan medføre økonomiske tab. En utilgængelig supportplatform kan forhindre virksomheden i at overholde sine forpligtelser over for kunderne.

ISO/IEC 27001 fastsætter anerkendte krav til et afgrænset ISMS. Punkt 4–10 omhandler organisationens kontekst, lederskab, planlægning, støtte, drift, evaluering af præstationer og forbedring. En organisation kan udvikle og drive et ISMS, før den søger certificering.

Ledelsessystemet skaber forbindelsen mellem de enkelte sikkerhedsforanstaltninger og forretningsbeslutningerne. En backup er en kontrol. At beslutte, hvad der skal kunne genoprettes, finansiere genopretningskapaciteten, teste den og handle på mislykkede test er arbejde i ledelsessystemet.

Hvorfor ledelsen har brug for sammenhængene

Sikkerhedsbeslutninger træffes allerede overalt i en virksomhed, uanset om den kalder det et ISMS eller ej. Nogen vælger en SaaS-udbyder, godkender privilegeret adgang, accepterer en forsinket patch eller forpligter sig til et krav om genopretning over for en kunde. Uden en fælles proces kan disse beslutninger bygge på forskellige antagelser og efterlade ingen ansvarlig for deres samlede virkning.

Et ISMS giver ledelsen et grundlag for at prioritere begrænsede ressourcer. Det hjælper også teams med at besvare kundespørgsmål ud fra vedligeholdte registreringer i stedet for at rekonstruere deres praksis ved hver salgsgennemgang. Det garanterer ikke et vellykket udfald af en indkøbsproces; det gør de underliggende påstande lettere at underbygge.

Sammenhængene bør besvare praktiske spørgsmål:

Disse forbindelser har særlig betydning under vækst. Uformel praksis, der fungerer, når alle kender hinanden, bliver upålidelig, når nye teams, lokationer, leverandører og kundeforpligtelser kommer til.

Definer et omfang, der afspejler forretningen

Begynd med forretningskonteksten, ikke med en liste over kontroller. Identificer de tjenester, organisationen leverer, de oplysninger de bruger, interessenter og deres krav samt de interne og eksterne forhold, der påvirker sikkerheden.

Omfanget definerer ISMS'ets afgrænsning. Det bør angive de omfattede aktiviteter, organisatoriske enheder, lokationer hvor det er relevant, teknologi og grænseflader til andre dele af virksomheden. Et brugbart første omfang kan dække et kundevendt produkt og driften af dets levering i stedet for alle virksomhedens aktiviteter.

Et fokuseret omfang kan dog ikke ignorere afhængigheder. Hvis HR igangsætter fratrædelsesprocessen for medarbejdere med adgang til produktet, har denne grænseflade betydning. Hvis en cloududbyder hoster tjenesten, forsvinder afhængigheden ikke, fordi den er outsourcet. Hvis support eksporterer kundeoplysninger, hører eksportprocessen med i analysen.

Skriv en omfangsbeskrivelse, og udfordr den derefter med tre spørgsmål:

• Kan en kunde forstå, hvad der er dækket, og hvad der ikke er?
• Har vi medtaget de afhængigheder, der er nødvendige for at beskytte den omfattede tjeneste?
• Kan navngivne ejere vedligeholde systemet inden for denne afgrænsning?

At begynde i det små er en praktisk anbefaling, ikke en tilladelse til at skabe en vildledende afgrænsning. Et klart omfang med ansvarlige ejere er stærkere end et stort register, som ingen opdaterer. Udvid bevidst, når nye tjenester eller afhængigheder begrunder det.

Tildel beslutninger, ikke kun opgaver

Den øverste ledelse skal give retning og støtte til et ISO 27001-ISMS. At uddelegere koordineringen til en sikkerhedsansvarlig overfører ikke ledelsens ansvar for prioriteter, ressourcer og acceptabel risiko.

Adskil de ansvarsområder, der ofte samles i én persons job:

En lille virksomhed kan tildele flere ansvarsområder til én person. Den bør stadig angive, hvilken rolle personen udøver, og hvor der er behov for uafhængig udfordring, især ved intern audit.

Definer eskaleringstærskler. En teamleder kan godkende en kortvarig driftsmæssig undtagelse inden for aftalte grænser; en risiko, der truer væsentlige kundeforpligtelser, kan kræve godkendelse fra direktionen. Registrer begrundelse, betingelser, udløbsdato og udløser for gennemgang. »Accepteret af ledelsen« er ikke nok, hvis ingen kan identificere beslutningstageren eller den accepterede eksponering.

Gør risikovurderingen til en prioriteringsproces

Risikovurderingen bør beskrive plausible scenarier, ikke blot nævne aktiver eller opremse svagheder. »Kundedatabase« er et aktiv. »En kompromitteret administratorkonto muliggør masseudtræk af kunderegistreringer« er et risikoscenarie med en årsag og en konsekvens.

Fastlæg en dokumenteret vurderingsmetode og kriterier for risikoaccept. ISO 27001 kræver ikke én bestemt scoringsformel. Som praktisk tilgang kan sandsynligheds- og konsekvenskategorier defineres i et sprog, jeres beslutningstagere forstår, herunder driftsforstyrrelser, økonomiske tab, kontraktlige konsekvenser og skade for enkeltpersoner, hvor det er relevant.

Registrer for hvert væsentligt scenarie:

• Den berørte tjeneste, de berørte oplysninger og afhængigheder.
• Truslen eller hændelsen og relevante sårbarheder.
• Eksisterende kontroller og deres kendte begrænsninger.
• Sandsynlighed, konsekvens og den resulterende prioritet.
• Risikoejeren og den foreslåede behandling.

Behandlingen kan bestå i at reducere eksponeringen gennem kontroller, undgå en aktivitet, dele dele af risikoen gennem kontrakter eller forsikring eller acceptere risikoen inden for godkendte kriterier. Forsikring gendanner ikke tabte oplysninger, og en leverandørkontrakt fjerner ikke organisationens ansvar.

Skeln mellem den aktuelle risiko og restrisikoen efter behandling. Sænk ikke en vurdering blot fordi en opgave er planlagt. Revurder efter implementeringen og passende dokumentation for driften. Indhent godkendelse af behandlingsplanen og accept af restrisikoen gennem den definerede beføjelse.

Det operationelle risikoregister bør forblive en beslutningsregistrering: hvad der ændrede sig, hvorfor en behandling blev valgt, og hvornår vurderingen skal gennemgås.

Vælg kontroller, og forklar deres anvendelighed

Kontroller er de foranstaltninger, der bruges til at ændre risikoen. De omfatter tekniske sikkerhedsforanstaltninger som multifaktorautentificering, organisatoriske processer som leverandørgennemgange, personrelaterede foranstaltninger som uddannelse og fysisk beskyttelse af enheder og lokaler.

Bilag A til ISO/IEC 27001:2022 indeholder 93 referencekontroller: 37 organisatoriske, 8 personrelaterede, 14 fysiske og 34 teknologiske. Udvælgelsen er risikobaseret; en organisation implementerer ikke automatisk alle kontroller. ISO/IEC 27002 giver implementeringsvejledning og er ikke et separat certificeringskrav til ISMS'et.

For ISO 27001 skal de kontroller, der er nødvendige for risikobehandlingen, fastlægges og sammenlignes med bilag A for at kontrollere, at ingen nødvendige kontroller er udeladt. Kontroller kan også være nødvendige på grund af lovmæssige eller kontraktlige krav, og de behøver ikke at være begrænset til bilag A.

Anvendelseserklæringen (Statement of Applicability) registrerer nødvendige kontroller, begrundelsen for at medtage dem, implementeringsstatus og begrundelsen for at udelade kontroller i bilag A. Den er adskilt fra risikobehandlingsplanen: Den ene forklarer det gældende sæt af kontroller; den anden forklarer de handlinger, der er nødvendige for at behandle risiciene. Se guiden til kontrollerne i bilag A for denne referencestruktur.

Definer for hver valgt kontrol en ejer, det tilsigtede resultat, hvordan den fungerer, og hvilken dokumentation der vil vise dens effektivitet. »Adgangskontrol implementeret« er mindre nyttigt end en eksplicit proces, der dækker godkendelse, tildeling, gennemgang og fjernelse.

Politikker bør fastsætte regler, som folk kan følge. Procedurer bør forklare udførelsen. Ingen af dem bør love gennemgange eller tekniske begrænsninger, som organisationen ikke reelt kan opretholde.

Indbyg dokumentation i den normale drift

Dokumentation bør opstå af selve arbejdet, ikke af at genskabe en historie før en audit. En adgangsgennemgang kan give en dateret brugerliste, bedømmernes beslutninger, sager om fjernelse og bekræftelse af, at ændringerne er sket. En genopretningsøvelse kan give testbetingelser, resultater, observerede begrænsninger og opfølgende handlinger.

Et skærmbillede kan vise en indstilling på ét tidspunkt. Det beviser ikke nødvendigvis, at indstillingen dækker alle relevante systemer eller forblev effektiv gennem en periode. Bedømmere bør undersøge omfang, dato, kilde, fuldstændighed og hvilken konklusion dokumentationen faktisk understøtter.

Et praktisk sæt ISMS-dokumentation omfatter:

Ikke hver række kræver et separat dokument. En lille organisation kan kombinere registreringer, så længe klarhed og sporbarhed bevares. Beskyt selve dokumentationen: Brugereksporter, hændelsesregistreringer og skærmbilleder kan indeholde følsomme oplysninger og bør have passende ordninger for adgang og opbevaring.

Gennemgået eksempel: en kundesupportplatform

Forestil jer en softwarevirksomhed med 30 medarbejdere, der bruger en SaaS-supportplatform. Antag, at platformen indeholder kundenavne, kontaktoplysninger, sagshistorik og lejlighedsvis vedhæftede diagnosefiler. Medarbejderne bruger individuelle konti, en ekstern udbyder hoster applikationen, og nogle sager eksporteres til fejlfinding. Det er antagelser for eksemplets skyld, ikke en foreskrevet virksomhedsmodel.

ISMS'ets omfang dækker kundesupportdriften og dens afhængigheder: medarbejderidentitet, SaaS-leverandøren, adgang fra endpoints, eksporter, opbevaring og genopretningsordninger. Supportchefen ejer tjenesten; IT driver adgangskontrollerne; indkøb koordinerer leverandørgennemgangen; ledelsen godkender risici ud over de delegerede beføjelser.

Den indledende vurdering identificerer tre scenarier:

Antag, at en kontoafstemning viser, at en tidligere medarbejder stadig har adgang. Den umiddelbare handling er at fjerne adgangen og vurdere, om kontoen er blevet brugt uhensigtsmæssigt. Handlingen i ledelsessystemet er at fastslå, hvorfor fjernelsen mislykkedes. Måske underrettede HR IT, men supportapplikationen manglede på tjeklisten for fratrædelser.

Den korrigerende handling opdaterer derefter applikationsfortegnelsen, tilføjer supportplatformen til fratrædelsesprocessen, tildeler ansvaret for bekræftelse og kontrollerer efterfølgende fratrædelser. At lukke sagen om fjernelse alene ville håndtere den umiddelbare tilstand uden at rette årsagen.

Antag nu, at SaaS-leverandøren ændrer sin liste over underdatabehandlere. Leverandørejeren gennemgår ændringen i forhold til kontraktlige, sikkerhedsmæssige og relevante databeskyttelseskrav. Vedkommende registrerer, om ændringen påvirker datahåndtering, afhængigheder eller accepteret risiko, og om der er behov for specialistgennemgang. Ændringen har en ejer og en gennemgangsvej i stedet for at ligge ulæst i en fælles postkasse.

Ledelsen modtager de uafklarede beslutninger: om der skal finansieres en stærkere reserveløsning, om mængden af oplysninger i vedhæftninger skal reduceres, eller om en defineret resterende eksponering skal accepteres. Det er ISMS'et, der forbinder operationelle fund med forretningsmæssige valg.

Kør en rytme, der kan opfange ændringer

Planlæg gennemgange efter risiko, ændringshyppighed og forpligtelser. En ugentlig gennemgang af mangler under den indledende implementering og en periodisk ledelsesevaluering kan være nyttige praktiske valg, men de er ikke universelle intervaller, som ISO 27001 kræver. Standarden kræver interne audits og ledelsens evalueringer med planlagte intervaller.

Tilføj hændelsesdrevne udløsere: sikkerhedshændelser, større releases, opkøb, leverandørændringer, nye retlige forpligtelser, væsentlige kundeforpligtelser og auditfund. En kalender alene vil overse vigtige ændringer mellem de planlagte møder.

Overvågning spørger, om kontroller og mål fungerer som tilsigtet. Intern audit vurderer, om ISMS'et opfylder kravene og er effektivt implementeret og vedligeholdt. Ledelsens evaluering tager stilling til systemets egnethed, tilstrækkelighed og effektivitet og træffer beslutninger om ændringer og ressourcer. Disse aktiviteter informerer hinanden, men kan ikke erstatte hinanden.

Ledelsen bør modtage beslutningsklare oplysninger: væsentlige risici, forsinkede behandlinger, gentagne fejl, auditfund, ændrede krav og ressourcebegrænsninger. At tælle færdige opgaver uden at undersøge resultaterne kan skjule svag præstation. Guiden til ISMS-målinger gennemgår nyttige mål.

Hændelsesstyring hører også med i denne cyklus. Definer indberetningsveje, vurderingskriterier, ansvar for reaktion, beføjelse til kommunikation og genopretningsordninger. Test kontaktveje og beslutningstagning gennem øvelser. Vurder de gældende underretningspligter i stedet for at antage, at én frist dækker alle hændelser.

Efter en hændelse eller en afvigelse skal det umiddelbare problem håndteres, årsagerne undersøges, korrigerende handlinger gennemføres og deres effektivitet evalueres. Gentagne fund er en grund til at genoverveje procesdesign eller ressourcer, ikke blot til at gentage den samme påmindelse.

Adskil ISMS, certificering og retlige forpligtelser

ISMS'et er det system, organisationen driver. ISO 27001 er en standard, som systemet kan vurderes op imod. Certificering udstedes af et uafhængigt certificeringsorgan, ikke af ISO eller Secani, og gælder for det angivne omfang.

Certificering kan være en nyttig sikkerhedsmekanisme, når kunder eller andre interessenter kræver det. Den er ikke bevis for, at alle virksomhedens aktiviteter er dækket, at alle kontroller altid virker, eller at hændelser ikke kan ske. Kontroller omfang og status i stedet for at betragte et certifikat som en sikkerhedsgaranti for hele virksomheden.

Den retlige anvendelighed kræver en separat analyse. GDPR artikel 32 kræver passende tekniske og organisatoriske sikkerhedsforanstaltninger baseret på de relevante risici. NIS 2-direktivet omhandler ledelsestilsyn, risikostyringsforanstaltninger og indberetning af hændelser for omfattede enheder gennem national gennemførelse.

Et ISMS kan organisere dokumentation og ansvarsområder, der understøtter sådanne forpligtelser, men certificering fastslår ikke overholdelse af GDPR eller NIS2. Det er heller ikke korrekt at sige, at et ISMS aldrig kan være lovpligtigt: Gældende nationale eller sektorspecifikke regler skal kontrolleres.

Undgå tre forudsigelige implementeringsfejl

At overtage skabeloner uændret. Skabeloner kan give en disposition, men ejerne skal validere hver forpligtelse op imod den faktiske praksis. En politik, der kræver gennemgange, som ingen udfører, skaber en ustyret mangel.

At trække en grænse, som ingen kan vedligeholde. En ambitiøs fortegnelse er ikke nyttig, hvis ejerskab og afhængigheder er uklare. Begynd med en forsvarlig tjenesteafgrænsning, og udvid derefter efter en eksplicit plan.

At betragte certificering som målstregen. Systemet skal fortsætte gennem personaleudskiftning, leverandørændringer, hændelser og nye produkter. Budgetter med drift, gennemgang og forbedring, ikke kun med den indledende dokumentation.

En beslægtet advarsel gælder ugennemgået automatisering. Automatisk indsamlede registreringer og AI-genererede resuméer kan understøtte arbejdet, men mennesker skal stadig afgøre relevans, vurdere mangler og godkende konklusioner.

Gør den første ledelsesbeslutning konkret

Vælg én repræsentativ tjeneste, og bed dens ejer om at medbringe en omfangsbeskrivelse, et afhængighedskort, indledende risikoscenarier, nuværende kontroller og uafklarede beslutninger. Aftal, hvem der kan acceptere risiko, hvilke ressourcer der er til rådighed, og hvornår fremdriften skal gennemgås. Det skaber et overskueligt udgangspunkt uden at foregive, at hele organisationen allerede er dækket.

Secanis workspace-model understøtter denne arbejdsgang ved at modellere tjenester og understøttende målobjekter, forbinde dokumentation med krav, kontroller og beslutninger og tildele ejere og ansvar for gennemgang. Teams kan gøre manglende dokumentation eller uklart ejerskab til opgaver. AI-understøttede forslag forbliver udkast til menneskelig gennemgang, og kilder og godkendelser holdes sporbare.

Den næste samtale i ledelsen bør derfor være konkret: Hvilken tjeneste beskytter vi først, hvilken eksponering kræver en beslutning nu, og hvilken dokumentation vil vise, at beslutningen virkede?