Modulet helt kort

Efter kontekstetablering er næste skridt i risikostyringen at modellere det system, der vurderes. Resultatet af denne proces er, at I får et overblik over systemarkitekturen og/eller dataflowdiagrammet. 

Formålet med systemmodellering

Det andet trin i risikovurderingen er systemmodellering, som går ud på at udarbejde en model af det system (eller produkt), der vurderes.

Formålet med systemmodellering er at identificere de komponenter, som systemet består af, og hvordan de interagerer med hinanden. Denne proces er udgangspunktet for at få en fælles forståelse af systemet og datastrømmene mellem komponenterne. Arkitekturen kan beskrives med større eller mindre detaljeringsgrad alt efter opgaven. 

"Systemmodellering" af CyPro under licens CC BY-NC-ND

Praktisk information

Før I begynder at kortlægge truslerne, skal der udarbejdes en model over det system, der vurderes – herunder tilhørende komponenter og deres indbyrdes afhængigheder.

Systemmodellering gennemføres typisk på en workshop ved brug af værktøjer, der er lavet specielt til formålet. Hvis I ikke ønsker at bruge et specifikt værktøj, skal I bruge et whiteboard/flipboard og nogle tusser, klistermærker, kuglepenne samt udskrifter af arbejdsarkene. Det anbefales at bruge papir/whiteboard fremfor en computer, så alle deltagere har mulighed for at bidrage.

Når I vurderer et eksisterende system/produkt, kan det også være en god idé at gennemgå eksisterende udviklingsdokumenter og henvise til dem gennem hele vurderingen.

Afsæt mindst en time til systemmodellering. Sørg for, at både personer med forretningsforståelse og teknisk indsigt deltager i processen. 

Systemmodellering

En vigtig del af risikostyringen er at have et klart billede af, hvad I ønsker at analysere, dvs. det fulde overblik over systemarkitekturen. En sådan oversigt gør det lettere at diskutere aktiver og trusler.  

For at sikre, at alle deltagere i workshoppen er enige om, hvad der analyseres, anbefales det at blive enige om nogle fælles definitioner. Kontekstetableringen giver allerede en overordnet afgrænsning/definition af systemet, men det kan være en god idé at genbesøge og tilrette beskrivelsen, hvis det er nødvendigt. Hvis der findes arkitekturdiagrammer eller andre tekniske beskrivelser, kan de også være et godt udgangspunkt. Vær dog opmærksom på, at arkitekturdiagrammer typisk indeholder en masse information, som det kan være udfordrende for ikke-teknikere at forstå.  

For at sikre, at alle deltagere har en forståelse af systemet, anbefales det derfor at udarbejde en overordnet skitse til at starte med, hvor der kun fokuseres på hovedkomponenterne. Det er fx meget almindeligt, at en klient og en server kommunikerer med hinanden på forskellige måder (REST, WebSocket osv.), ligesom serveren internt kan bestå af forskellige mikrotjenester. At indtegne alle disse detaljer i diagrammet kan hurtigt blive ret overvældende, og oplysningerne skal først bruges senere i forbindelse med Analyse af aktiver og Kortlægning af trusler. I stedet skal fokus være på hovedkomponenterne, mens kommunikationen mellem A og B bare kan markeres på diagrammet. 

“Tegn systemet” af CyPro under licens CC BY-SA 4.0

Tegn dit system
Print-venlig version i stort format

Trin-for-trin guide

Systemmodellering består af følgende trin:

1. Kortlægning af komponenterne
   Lav en brainstorm over de komponenter, systemet består af. Husk at medregne både interne og eksterne komponenter.  
2. Kortlægning af hvordan komponenterne interagerer 
   Kortlæg, hvordan komponenterne i systemet interagerer.  
3. Forståelse af dataflowet 
   Lav en brainstorm over de data, der er nødvendige, for at systemet fungerer. Forstå, hvordan data flyder på tværs af forskellige komponenter, og hvor data er placeret og gemt. Det kan være, der skal tilføjes nye komponenter, eller at eksisterende komponenter kan slås sammen til én.
4. Markering af trust boundaries  
   Markér, hvor der er en trust boundary mellem komponenterne. En trust boundary er områder i systemet med forskellige niveauer a tillid. Komponenterne kan samles inden for én trust boundary, hvis de fx kører på samme server. Man kan også bruge trust boundaries til at afgrænse enkeltkomponenter, fx en ekstern enhed. 

Find yderligere inspiration i eksemplet med IoT-dørlåsen nedenfor. 

"Systemmodellering trin-for-trin" af CyPro under licens CC BY-NC-ND

Eksempel: IoT-dørlås

Gennem hele risikostyringsprocessen bruges en IoT-dørlås som gennemgående eksempel.

Eksemplet viser et netværk bestående af hardware-, software- og kommunikationssystemer, herunder IoT-dørlåshardwaren med et kommunikationsmodul, en hub, en mobilapplikation til fjernadgang og en cloud-infrastruktur til datalagring og -behandling. 

"IoT-dørlåsesystem" af CyPro under licens CC BY-SA 4.0

1. Kortlægning af komponenterne
   Lav en brainstorm, hvor I oplister alle de komponenter, som IoT-dørlåsesystemet består af. Der er både interne og eksterne elementer, såsom: 
   1. IoT-dørlås: Den primære hardware installeret ved indgangen, som er udstyret med et kommunikationsmodul og låsemekanisme.
   2. IoT-gateway: En fysisk enhed, der fungerer som en hub, der forbinder dørlåsen til cloud for at sikre effektiv kommunikation.
   3. Cloud-servere: Den cloud hosting-infrastruktur, hvor data behandles, gemmes og administreres.
   4. IoT-applikationer: De softwaregrænseflader, som slutbrugere anvender til at styre og overvåge systemet.
   5. Slutbrugere: Personer, der interagerer med systemet via mobilappen eller den fysiske enhed.
   6. Forretningssystemer: Eksterne systemer, der er integreret med IoT-platformen og bruges til overvågning, analyse eller drift. 
      
      
2. Kortlægning af hvordan komponenterne interagerer
   Dernæst kortlægges, hvordan disse komponenter interagerer med hinanden. For eksempel:
   1. IoT-dørlåsen sender og modtager kommandoer gennem IoT-gatewayen.
   2. IoT-gatewayen fungerer som en bro, der overfører data til og fra cloud-serverne.
   3. Cloud-serverne behandler data og kommunikerer dem til IoT-applikationerne til brugerinteraktion.
   4. Slutbrugere bruger applikationerne til at sende kommandoer eller overvåge systemet.
   5. Forretningssystemer interagerer med IoT-applikationerne ved avancerede funktioner såsom adgangsovervågning eller rapportering. 
      
      
3. Forståelse af dataflowet
   Her ser vi på, hvordan data flyder mellem komponenter, og hvor de gemmes. De primære datastrømme er:
   1. Fra IoT-dørlås til IoT-gateway: Data om fx låsens status, batteriniveau og sikkerhedsadvarsler.
   2. Fra IoT-gateway til cloud servere: Logfiler (fx adgangshistorik, systemlogs og diagnosticeringslogfiler), sikkerhedsadvarsler, kommandoer og systemopdateringer.
   3. Fra cloud-servere til IoT-applikationer: Behandlede oplysninger, opdateringer i realtid og meddelelser til brugere.
   4. Mellem IoT-applikationer og forretningssystemer: Dataudveksling til analyse og generel systemintegration. 
      
      
4. Markering af trust boundaries
   Til slut markerer vi trust boundaries for at vise steder med forskellige tillidsniveauer.
   For eksempel:
   1. IoT-dørlåsen og IoT-gatewayen er inden for samme trust boundary, da de er fælles om det lokale netværk (vist på figuren nedenfor). Bemærk, at vi går ud fra, at gatewayen er en integreret del af systemet.
   2. Kommunikation mellem IoT-gatewayen og cloud-servere krydser en trust boundary, hvilket kræver sikre internetprotokoller.
   3. Cloud-serverne og IoT-applikationerne opererer inden for den samme infrastruktur og har en delt trust boundary.
   4. Interaktioner mellem IoT-applikationer og slutbrugere udgør en trust boundary, hvor godkendelse og sikker adgang er afgørende.
   5. Dataudveksling mellem IoT-applikationer og forretningssystemer udgør en anden trust boundary, der skal muliggøre sikker og kontrolleret dataintegration. 

"IoT-dørlåsesystem med den markerede trust boundary"af CyPro under licens CC BY-SA 4.0

Udbytte

Resultatet af processen er et diagram over systemet og dets dataflow. Diagrammet giver et et overblik over systemet, og hvordan det interagerer med eksterne enheder. De trust boundaries, I har noteret, viser, hvor meget kontrol I har (eller ikke har) over disse komponenter og giver dermed en indikation af potentielle angrebsflader.

Ekspertens råd

I kan med fordel inddrage personer med både forretningsforståelse og teknisk indsigt i systemmodelleringsarbejdet, da det hjælper med at opbygge en fælles forståelse af systemet.

Næste skridt

Når systemdiagrammet er færdigt, er næste skridt at få identificeret de aktiver, der er vigtige for organisationen. Det er beskrevet mere udførligt i Kortlægning af aktiver.

Indholdselementerne ovenfor er udviklet gennem projektet:
’CyPro – Cybersikker produktion i Danmark’ af Aarhus Universitet, Alexandra Instituttet, DAMRC, UGLA Insights og FORCE Technology støttet af Industriens Fond. Materialet fra projektet er offentliggjort under Creative Commons.

CyPro