Hvornår er en sikkerhedskontrol implementeret?
Netop spørgsmålet om, hvornår en sikkerhedskontrol er implementeret, har jeg ofte fået og forsøgt at svare på.
Man skulle umiddelbart tro, at svaret er enkelt. Men i praksis er det ikke helt så ligetil.
Ofte vil den implementeringsansvarlige, den sikkerhedsansvarlige, compliancefunktionen og den uafhængige revisor have hvert sit bud på svaret.
Det er der flere årsager til. En del af udfordringen er, at sikkerhedskontroller kan se meget forskellige ud, og at vi ikke altid mener det samme, når vi siger, at en kontrol er “implementeret”.
Det ser vi nærmere på i det følgende. Til sidst kommer jeg også med mit bud på, hvornår man med rimelighed kan sige, at en kontrol er implementeret.
Kontroller kan se meget forskellige ud
ISO 27002-standarden opdeler eksempelvis sikkerhedsforanstaltninger i fire overordnede temaer: organisatoriske, personrelaterede, fysiske og teknologiske foranstaltninger.
Standarden bruger betegnelsen foranstaltninger. I dette indlæg bruger jeg primært betegnelsen kontroller.
En kontrol kan derfor være alt fra en politik eller en proces for håndtering af leverandører til screening før ansættelse, fysisk adgangskontrol eller MFA.
Og implementering ser naturligvis forskellig ud.
For teknologiske kontroller kan implementering umiddelbart virke forholdsvis enkel at fastslå.
MFA er aktiveret. EDR-agenten er installeret. Logging er slået til. En firewallregel er konfigureret.
Men allerede her opstår de første nuancer.
Hvis EDR er installeret på 92 procent af organisationens endpoints, hvad betyder det så, når vi siger, at kontrollen er implementeret?
Vi kan konstatere, at EDR er etableret og taget i brug på 92 procent af organisationens endpoints. Men om de 92 procent er tilstrækkeligt, er et andet spørgsmål. Det afhænger blandt andet af, hvilke endpoints der burde være omfattet, hvilke risici kontrollen skal håndtere, og hvilke krav organisationen skal efterleve.
Det samme gælder, hvis MFA er aktiveret for alle almindelige brugere, men bestemte systemer eller administrative konti er undtaget, eller hvis logging er aktiveret, men ikke omfatter de hændelser, som kontrollen skal bidrage til at opdage.
Allerede her bliver det derfor tydeligt, at vi let kommer til at blande spørgsmålet om, hvorvidt en kontrol er implementeret, sammen med spørgsmålet om, hvorvidt kontrollen er tilstrækkeligt designet.
Det samme gælder andre typer kontroller.
En fysisk adgangskontrol kan være etableret ved nogle indgange, men ikke andre. En proces for screening før ansættelse kan være etableret og taget i brug for bestemte medarbejdergrupper. En sikkerhedspolitik kan være godkendt og kommunikeret, uden at alle de processer og handlinger, den stiller krav til, nødvendigvis er etableret.
I alle tilfælde kan vi beskrive, hvad der faktisk er etableret og taget i brug. Om kontrollens omfang og udformning er tilstrækkelig i forhold til relevante risici og krav, er en anden vurdering.
Kontrollens karakter har derfor betydning for, hvad der konkret skal være på plads. Men den fortæller ikke i sig selv, hvad vi mener med implementeret.
Hvad forstås ved implementeret?
Eksemplerne ovenfor viser, at flere forskellige spørgsmål ofte bliver blandet sammen, når man taler om, hvorvidt en kontrol er implementeret.
I praksis kan vi være interesserede i forskellige ting:
- Er kontrollen hensigtsmæssigt designet?
- Er den faktisk etableret?
- Er den taget i brug?
- Fungerer den som tiltænkt over tid?
- Kan vi dokumentere og verificere det?
Det er beslægtede spørgsmål, men de er ikke ens.
Det kan derfor være nyttigt at skelne mellem flere elementer i vurderingen af en kontrol:
- Krav: Hvad skal vi opnå eller efterleve?
- Design: Hvordan skal kontrollen fungere, og hvilken risiko eller hvilket krav skal den adressere?
- Implementering: Er kontrollen faktisk etableret og taget i brug?
- Kontinuerlig drift: Fungerer kontrollen som tiltænkt over tid?
- Verifikation: Kan vi dokumentere og efterprøve vores konklusioner?
Opdelingen er vigtig, fordi en kontrol godt kan være implementeret, selv om designet viser sig at være utilstrækkeligt.
Hvis organisationen eksempelvis har besluttet, at MFA kun skal anvendes på bestemte systemer, og MFA er etableret og taget i brug på disse systemer, kan kontrollen være implementeret. Det betyder ikke nødvendigvis, at afgrænsningen er hensigtsmæssig i forhold til organisationens risiko eller relevante krav.
På samme måde kan en kontrol være hensigtsmæssigt designet og implementeret, uden at organisationen dermed har dokumenteret, at den har fungeret som tiltænkt over tid.
Fire perspektiver på implementering
Når jeg oplever forskellige svar på, om en kontrol er implementeret, skyldes det ikke nødvendigvis, at nogen tager fejl. Det skyldes ofte, at spørgsmålet bliver besvaret fra forskellige perspektiver.
Den ansvarlige for implementeringen af en given kontrol, sikkerhedsfunktionen, compliancefunktionen og en revisor vil ofte have forskellige svar på, hvornår kontrollen kan betragtes som implementeret. Det ser vi nærmere på i det følgende.
Den ansvarlige: Er kontrollen etableret og taget i brug?
For den ansvarlige for implementeringen af en given kontrol handler det om at få kontrollen omsat fra beslutning til faktisk anvendelse. Det kræver ofte, at:
- ansvaret er placeret og forankret i organisationen
- de nødvendige arbejdsgange er etableret
- de involverede er trænet i, hvad de skal gøre
- nødvendige systemer, data og værktøjer er tilgængelige
For en teknologisk kontrol kan det være, at løsningen er installeret og konfigureret og faktisk anvendes. For en screeningsproces, at den er etableret og anvendes. For en organisatorisk kontrol, at de nødvendige roller og processer er etableret og taget i brug.
Set fra dette perspektiv handler implementering i høj grad om at sikre, at kontrollen er i brug i praksis.
Sikkerhed: Håndterer kontrollen den relevante risiko?
Fra et sikkerhedsmæssigt perspektiv er det ikke nok, at kontrollen eksisterer. Her bliver spørgsmål om design, dækningsgrad og funktion centrale.
MFA kan være implementeret, men stadig udelade systemer eller adgangsveje, der udgør en væsentlig risiko. En screeningsproces kan være etableret og taget i brug, men niveauet af screening kan være utilstrækkeligt i forhold til de berørte roller.
En kontrol kan med andre ord være implementeret og stadig være utilstrækkelig.
Derfor skal både design og implementering være på plads, hvis kontrollerne skal tilføre værdi for organisationen.
Jeg har desværre alt for ofte set generisk designede kontroller, der ikke tager højde for organisationens kontekst eller risici. Omvendt har jeg mindst lige så ofte set kontroller, der er designet og fungerer godt på papir, men som aldrig er blevet omsat til praksis.
Begge dele er spild af ressourcer og kan samtidig give en falsk tryghed for, at sikkerheden er på plads.
Compliance: Opfylder vi kravet?
Compliance tilfører endnu et perspektiv.
Her er spørgsmålet, om organisationen opfylder det regulatoriske, kontraktuelle eller interne krav, som kontrollen skal bidrage til at efterleve.
Hvilket krav skal kontrollen adressere? Hvad kræver det konkret? Hvilke dele af organisationen er omfattet? Og er kontrollen designet og implementeret på en måde, der opfylder kravet?
En kontrol kan give reel sikkerhedsmæssig værdi uden fuldt ud at opfylde et specifikt compliancekrav. Omvendt er opfyldelsen af et konkret krav ikke i sig selv bevis for, at den bagvedliggende risiko er håndteret tilstrækkeligt.
Tilsyn og revision: Hvad kan verificeres?
Fra et revisionsperspektiv bliver det afgørende at være præcis omkring både konklusionen og grundlaget for den.
Det er ikke tilstrækkeligt, at organisationen fortæller, at kontrollen er implementeret. Der skal være et tilstrækkeligt grundlag for at konstatere, at kontrollen faktisk eksisterer og er taget i brug.
Jeg har ofte oplevet, at netop dokumentationen for, om og hvordan en kontrol i praksis udføres, ikke er på plads.
En procedure kan eksempelvis vise, hvordan en kvartalsvis gennemgang og revurdering af brugeradgange er designet. Men proceduren dokumenterer ikke i sig selv, at kontrollen også er implementeret. Det kræver, at vi kan konstatere, at kontrollen faktisk er etableret og anvendes i praksis. En revisor vil ikke kunne udtale sig om en kontrols faktiske implementering uden tilstrækkeligt bevis for, at den er etableret og taget i brug. I praksis har revisor forskellige muligheder for at verificere kontrollens implementering. Det kan fx ske gennem observation af, hvordan kontrollen udføres, eller gennemgang af dokumentation.
Revisor vil typisk også være interesseret i, om kontrollen er hensigtsmæssigt designet, og om den efterfølgende har fungeret effektivt over tid. Det er imidlertid særskilte vurderinger.
I revisionsmæssig sammenhæng vil man ved den sidste vurdering typisk tale om kontrollens operationelle effektivitet. En kontrol kan være implementeret på et bestemt tidspunkt, uden at man dermed kan konkludere, at den har fungeret som tiltænkt gennem en efterfølgende periode.
Det sidste kræver et andet grundlag for konklusionen og er ikke fokus for dette indlæg. Du kan læse mere om forskellige former for verifikation, og hvad de kan fortælle os om sikkerheden, i dette indlæg.
Dokumentation er ikke kontrollen
Når noget skal kunne verificeres, opstår der hurtigt et stort fokus på dokumentation.
Det er nødvendigt. Men dokumentationen må ikke forveksles med selve kontrollen.
Et udfyldt regneark med 500 brugeradgange dokumenterer ikke nødvendigvis, at der er gennemført en periodisk revurdering af de 500 adgange. Et flueben i et GRC-system dokumenterer heller ikke i sig selv, at kontrollen fungerer. Og et kursusbevis dokumenterer, at en medarbejder har gennemført træning, men ikke nødvendigvis at indholdet er forstået eller anvendt.
Dokumentationen skal gøre det muligt at forstå, hvad der er sket, hvem der har udført kontrollen, hvilket omfang den havde, hvad resultatet var, og hvordan eventuelle afvigelser blev håndteret.
Formålet er ikke dokumentationen i sig selv. Formålet er at gøre kontrollens udførelse og funktion verificerbar. Det er netop det, en revisor vil lægge vægt på ved en uafhængig verifikation af kontrollen. Tilsvarende bør det være relevant for den kontrolopfølgning, som første og anden forsvarslinje gennemfører som led i det periodiske tilsyn med efterlevelsen af de etablerede kontroller.
Du kan læse mere om ansvarsfordelingen mellem de tre forsvarslinjer i dette indlæg.
Så hvornår er en kontrol implementeret?
Som lovet i indledningen er det vist på tide med mit eget svar på spørgsmålet om, hvornår en kontrol er implementeret.
Jeg er givetvis påvirket af min baggrund fra revision og foretrækker derfor at holde definitionen af implementeringsbegrebet relativt snæver. Jeg vil som udgangspunkt betragte en kontrol som implementeret, når det kan verificeres, at den er etableret og taget i brug i den sammenhæng, den skal fungere i.
Det kræver, at vi kan svare ja til tre spørgsmål:
- Er kontrollen faktisk etableret?
- Er den taget i brug?
- Og kan vi verificere det?
Mit svar er, som nævnt, tæt på den måde, man typisk vil adskille design, implementering og operationel effektivitet i en revisionsmæssig vurdering. Det er også en sondring, jeg finder nyttig uden for revision, fordi den gør det tydeligt, hvordan vurderingen af de forskellige elementer skal udføres og på hvilke tidspunkter de kan gennemføres.
Særligt tidsperspektivet er interessant her. Kontrollens design kan vurderes, når kontrollen er beskrevet. Vurdering af implementeringen kræver derimod, at kontrollen er taget i brug, og at der er tilstrækkeligt grundlag for at verificere, at den anvendes i praksis. Vurderingen af den operationelle effektivitet kræver yderligere grundlag for at vurdere, om kontrollen har fungeret som tiltænkt gennem en relevant periode.
Der er altså tale om tre særskilte vurderinger:
- Om kontrollen er hensigtsmæssigt designet i forhold til relevante risici og krav,
- Om den faktisk er implementeret, og
- Om den har fungeret som forventet over tid
Alle tre vurderinger er vigtige, hvis målet er kontinuerlig efterlevelse af relevante krav og reduktion af identificerede sikkerhedsrisici.