Praktisk bruk av DPIA del 2: En sikkerhetsrådgivers erfaringer med GDPR i praksis

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. 

Erfaringer med å gjøre dette til en årlig gjentakende aktivitet

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. 

Flere typer kritikalitet i ett skjema

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. 

Lettere oversikt over tiltak

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. 

Flere bruksområder - CMDB Light

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: 

• If a system is inserted into a CMDB; it can be monitored, 

• • Can a system be monitored then it can be “assessed for critically” 

• • • Can a system be assessed, then it can be classified 

• • • • Can a system be classified, then handling rules can be set up 

• • • • • if a system is given handling rules; then you can perform self-control activities to see how well you comply with the rules 

• • • • • • In case of self-assurance, this must be reported as an Internal Control activity (as Compliance with described procedures)
            
            

• If a system is inserted into a CMDB, then there may be defined dependencies to other systems 

• • Have you described the dependencies, you can show the criticality of the work process 

• • • If you know the entire process's criticality, you can take action on the weakest links and monitor risk reduction 

• • • • Can you associate event reporting with the items and estimate losses in money spent; then you can calculate a reduction in lost income when implementing security measures 
        
        

• Are the systems in the CMDB classified according to their criticality; contingency plans can be made 

• • are the systems classified “High/Critical” grouped together; then that group is also those systems where you want to monitor Internal control over time to reduce unforeseen events 

• • • By reducing the number of unforeseen events, unforeseen costs and the risk of a crisis are reduced 
      
      

• In order to be able to classify, management must express what they regard as acceptable risk levels 

• • In order to implement the right measures, one must focus on areas where the gap between real risk and acceptable risk is large 

• • • 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. 
      
      

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. 

Bearbeiding av analyseresultatene i vår CMDB

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 following database elements are defined till now for infrastructure:

• • • PC
    • Network component 
    • Server component 
      
  • The following database elements are defined till now for Software applications
    • Bespoked applications 
    • Off the shelf applications 
      
  • The following database elements are defined till now for Database components
    Oracle DB? 
    • Microsoft SQL?
      
    • <name your own>….?

• 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: 

• Update each Configuration Item (CI or “Target of Evaluation”-TOE) with their criticality for the business (and GDPR)
   
• Update each CI with information from the PC agent 
  
  
• Update each CI with classification and priority information as defined in the SLA/OLA 
  
  
• Update each CI with the security safeguards and measures used to protect it. 
  
  
• Update each CI when an Incident, Change or Problem has occurred that affects the CI 
  
  

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.