I det forrige innlegget beskrev jeg kort bakgrunnen og metoden bak en enkel risikoanalyse og/eller en simpel DPIA. I dette innlegget presenterer jeg erfaringer med bruk av dette hos virksomheter.
Les "Praktisk bruk av DPIA del 1: En sikkerhetsrådgivers erfaringer med GDPR i praksis" her.
Vi forutsetter at man har gjennomført risikoanalysene det første året slik ISO 27001 og GDPR krever. Året etter er det da lett å ta for seg regnearket, sortere på systemeier og spørre denne om noe har endret seg. Ting som utfasing av en løsning, eller at nye moduler er tatt i bruk; kan heve eller senke kritikaliteten på systemet. Vi ser at når en systemeier får en slik enkel oversikt vil majoriteten lett kunne svare at alt er OK, eller at enkelte justeringer bør foretas. Og en minoritet vil ikke gjøre noe før du har purret dem flere ganger. Slik er mennesket skrudd sammen. Men vi ser at når vi gjør dette i år 3 og år 4, blir det færre og færre personer som må purres. De fleste forstår nytten og føler en tilfredshet og en trygghet i det at de får meldt fra hva status er for «deres» system. Jeg kaller dette gjerne for en «årshjulsaktivitet». Noe som skaper modenhet og forbedringer i en virksomhets IT-prosesser.
Som tidligere nevnt har man mulighet til å lage en total systemoversikt hvor kritikalitet for alle systemer vurderes basert på deres forretningssensitive informasjon. (Company Sensitive Information -CSI). I tillegg kan man vurdere de systemer som inneholder «GDPR-informasjon» (Personal Identifiable Information – PII) etter hvor kritisk informasjonen er for det enkelte individ. Og dersom man ønsker eller har behov for det, kan man også vurdere systemene som behandler eller inneholder betalingsinformasjon (Payment Card Information – PCI) i den samme oversikten. Det at et system kan inneholde alle 3 informasjonstypene gjør at man må tenke annerledes med hensyn på sikringstiltak enn for et system som bare behandler en type informasjon.
Bilde av regneark
Her ser man at et system kan være kritisk for virksomheten (venstre fargekolonner), men ikke kritisk i forhold til GDPR (høyre fargekolonner); eller motsatt. Man ser også om det er Konfidensialitet, Integritet eller Tilgjengelighet som er avgjørende å iverksette tiltak for å sikre. Noen ganger kan man etablere generelle tiltak som hever sikkerheten i alle systemer, og noen ganger må tiltakene være systemspesifikke.
Det å ha denne komplette oversikten samlet, gjør det enklere å vurdere om relevante tiltak skal være preventive, detekterende eller korrigerende. Eller «proaktive kontra reaktive tiltak». Det er først når man begynner å benytte resultatene av DPIA på denne måten at alle fordelene med innsatsen kan plukkes som «low hanging fruits». Det er min erfaring at da begynner også ledelsen i en virksomhet å engasjere seg i dette, fordi de ser at analysene hjelper dem i å treffe bedre og sikrere beslutninger.
I selskaper jeg har jobbet for, bruker man nå disse listene som referanser blant annet for hvilke systemer man har «in-house» kontra «outsourced», man benytter dem til å verifisere at tiltak gjort på server-nivå faktisk avhjelper det å lukke de mest utsatte sårbarhetene i de forretningskritiske systemene, og man ser at dette gir bedre driftsbehandling og bedre datahåndtering.
Og ikke minst bruker man oversikten over hvor kritisk hvert enkelt system er i samtaler med en IT drift-leverandør for å bestemme “Impact” dimensjonen med hensyn på Incident behandling i deres Servicedesk system som ofte har 2 dimensjoner – Impact og Urgency. Nå har endelig Kunden mulighet til å bestemme “Impact” (altså hvor kritisk systemet er for virksomheten), mens servicedesk personell bestemmer “Urgency” for den enkelte incident som rapporteres inn.
Regnearket vi brukte i risikoanalysene inneholder altså mange opplysninger om systemer og kan derfor danne grunnlag for en enkel «konfigurasjonsoversikt over systemer».
Å bruke denne form for enkel Configuration Management DataBase (CMDB) er etter min mening en av de mest oversette verktøyene man har når man jobber med informasjonssikkerhet. De aller fleste gjør aktiviteten med å ajourholde oversikten mest som en plikt, og legger resultatet bort til neste år. I stedet vil en god fagperson se at dette danner grunnlag for å vurdere konkrete tiltak for de mest forretningskritiske systemene basert på hvor man faktisk er mest sårbar ved en hendelse. Er det konfidensialitet, så hjelper det ikke å jobbe med backup-løsninger; er det integritet, så hjelper ikke tiltak for bedre tilgangskontroll osv. Her kommer en liten regle på engelsk:
The Company will carry out implementation of Criticality analyzes for all systems, which will be filed into a Configuration Management Database (CMDB). This philosophy outlined below explains why assessments will cover more needs regulated by the SLAs:
For proposed actions to be taken, system owners must be held responsible, and the quality of the object and execution of agreed actions are monitored and followed up on a regular basis.
Så en liten beskrivelse av hvordan den enkle risikoanalysen /DPIA’en kan utføres og samtidig oppdatere vår simple CMDB i samme omgang. Den som utfører risikoanalysene, er gjerne ansvarlig for informasjonssikkerhet (CISO). Men i tillegg til CISO vil gjerne Konfigurasjonsansvarlig (ansvarlig for CMDB hos IT drift-leverandøren) ofte kunne utnytte resultatet i sitt arbeid. Og Lederen for ServiceDesk vil høste fruktene av dette ved å gi riktig respons til incidenter basert på systemenes kritikalitet. Her kommer en generisk rutinebeskrivelse om hva en Configuration Manager skal gjøre:
The Configuration Manager prepares and adjusts the CMDB overview layout with defined “Company Configuration Details” for each system.
The routine works as follows:
When establishing a NEW database element, the CMDB Manager consider whether there is a need to create and update the configuration documentation in the database.
The status is reported to the CMDB Manager together with suggestions for a new description of the configuration parameters.
The CMDB Manager forward the information to the Configuration Manager for final decision.
Maintenance of the CMDB is provided by the Configuration Manager and contain:
Her ser man at et system kan være kritisk for virksomheten (venstre fargekolonner), men ikke kritisk i forhold til GDPR (høyre fargekolonner); eller motsatt. Man ser også om det er Konfidensialitet, Integritet eller Tilgjengelighet som er avgjørende å iverksette tiltak for å sikre. Noen ganger kan man etablere generelle tiltak som hever sikkerheten i alle systemer, og noen ganger må tiltakene være systemspesifikke.