Som du sikkert vet godt allerede så er data i dag verdt mer enn olje, men i motsetning til naturstoffer så blir det ikke mindre av det. Den globale datamengden i dag vokser så fort at man regner med at 1,7 MB data blir produsert av alle mennesker hvert sekund. Det er heller ikke slik at du bare kan selge en slump med data og så blir du rik.
Data i seg selv har verdi, men den virkelige verdien ligger i hvordan du bruker den og hvordan du kobler flere datakilder sammen til et nytt datasett som kan gi deg helt nye spørsmål og svar. Hvordan kan dataene optimalisere dine forretningsleveranser, minimere kostnad, øke effektivitet, og kanskje til og med finne helt nye måter du kan styre forretningen på? Eller enda mer drastisk; gjøre deg kapabel til å starte en reise du tidligere ikke en gang hadde på radaren? I en veldig kort periode var det en lett bris på sjøen som gjorde navigasjonen enkel. Men det er verre i dag.
«Akkurat nå sitter du med så mye data at du sannsynligvis ikke vet hva alt er, hvor det ligger, hvem som har tilgang til det...»
Akkurat nå sitter du med så mye data at du sannsynligvis ikke vet hva alt er, hvor det ligger, hvem som har tilgang til det, om noen i det hele tatt kikker på den eller analyserer den eller om du har alt innenfor hva loven krever. Jeg vil tro de fleste store og mellomstore bedrifter og virksomheter, samt de små, bruker data de har tilgang på i dag for å spare eller tjene penger, yte flere tjenester eller forbedre de tjenestene de har.
De som ikke har et aktivt forhold til dataene sine lever på overtid og vil slite fremover. Kunder forventer at du er i evig endring og forbedring, både for miljø og tjenester, og alle konkurrentene du bør bry deg om er allerede i gang. Det positive for deg som enda ikke har kommet i gang skikkelig er at du har fortsatt mulighet til å hevde deg i teten.
Behov for data lifecycle management
Det er ikke enkelt å kontrollere noe som nesten lever et organisk liv i etheren din. Hva er masterdatabasen eller datavarehuset til all informasjonen din? Hvor ligger alle dataene dine nå som du bruker to skyleverandører av en norsk driftsleverandør på en del av den eldre dataen, ansatte som legger data på arbeidsmaskinene sine, og de backupene som kanskje ligger på bånd hos den driftsleverandøren du hadde for ti år siden? Hvem eier eller har ansvar for hva du prosesserer og hvordan du prosesserer det?
For å kunne jobbe med all denne informasjonen slik at den leverer ønskede resultater og ikke hodebry, og at den i tillegg gjør det på en lovlig, sikker og forutsigbar måte, trenger vi et data management lifecycle system.
Stortinget trenger flere sikkerhetsfolk: - Men kompetansen mangler
Et data lifecycle management system er kort fortalt din praktiske tilnærming til hvordan du metodisk jobber med data for å kunne si at du har god data governance, eller datastyring på godt norsk. Dette handler om styring av tilgjengelighet, integritet, sikkerhet og bruk av dataene dine.
Datastyring gjør at det halvspilte sjakkbrettet som du har overtatt, hvor det hele tiden legges til flere brikker mens brettets størrelse aldri utvides, skal kunne formes med taktiske og strategiske beslutninger og handlinger. Datastyring er dine menneskelige, teknologiske og metodiske kapabiliteter som skal gi deg bedre beslutningsgrunnlag, bedre risikostyring, og bedre samsvar med lover og regler.
Risikoområder og datatilgang
Datastyring er ønskelig for å unngå at risikoer blir så store at det til slutt er uunngåelig at en hendelse inntreffer. Konsekvensene av å miste sine data, eller at dataene ikke lengre kan stoles på, kan i verste fall bety kroken på døra. Det kan være fordi du ikke har noen forretning uten dataene dine eller fordi bedriften ender med saftige bøter fordi de ikke har tatt datasikkerheten seriøst nok.
Å sitte på data i dag innebærer et enormt ansvar, spesielt hvis det er persondata, og i enda større grad hvis dataene dine er ansett som sensitive. Vi ønsker å vite hvor dataene våre er til enhver tid. Vi ønsker også å ha kontroll på hvordan vi får all dataene, hvordan de håndteres og brukes, og ikke minst hvordan de må sikres. Dette må gjøres i henhold til GDPR og andre relevante lover, regler og forskrifter.
Hver tiende nordmann takler ikke totrinns-bekreftelse
Vi trenger å fokusere på klassifisering av data. Det inkluderer katalogisering av metadata og kvalitetssikring av dataene og metadataene. Vi må også følge noen viktige prinsipper for datatilgang:
- Least privilege: Det betyr at du kun skal ha tilgang til det du trenger for å utføre jobben din og ikke noe mer
- Separation of duties: Ingen bruker skal ha så mye tilgang at den alene kan misbruke systemet
- Fail-safe defaults: Med mindre noen har gitt deg spesifikk tilgang til et objekt skal du ikke ha tilgang
Man kan møte på personer som ikke ser viktigheten og verdien av dette når det legges frem fordi sikkerhet aldri blir prioritert nok. Da er det viktig å poengtere at det er kun når man har fokus på sikkerhet at man er i stand til å være dynamisk. Da kan man ta flere sjanser fordi man kjenner risikoene og har utarbeidet tiltak. Da kan du være fremoverlent samtidig som du opererer etter dine kunders beste og følger loven. Sikkerhet er en muliggjører og ikke et hinder.
Sikker datastyring
Livssyklusene til en mengde data består av seks faser, men det er ikke slik at all data nødvendigvis er innom alle fasene. I senter av det hele ligger tilgangsstyring (IAM – Identity and Access Management).
Hva finner vi i hver fase og hvilke kapabiliteter trenger vi for å utføre oppgavene i hver fase innenfor ønskede trygge rammer? Og kanskje minst like viktig; hvordan vet vi at vi gjør nok?
Opprettelse av data
Vi kan innhente data på hovedsakelig tre ulike måter:Den første er å hente data fra en tredjepart som partnere, offentlig informasjon, kunder og lignende. Den andre er at dine ansatte oppretter data manuelt eller ved bruk av IT-systemer, og den tredje er når automatiserte IT-systemer lager data når de kjører (alt fra logger til data skapt via prosesser som enten brukes direkte eller bare ender opp et sted). Det som er viktig her er datatyper, overføringsformatet til dataen, kommunikasjonsprotokoller, datakilder, mellomlagring og datamengder.
Autentisering og autorisasjon er ofte nødvendig både for eksterne og interne brukere. Det kan hende vi bare ønsker data fra avsendere vi har et forhold til på en eller annen måte. Vi ønsker å verifisere at de er de vi forventer at de er og at de har lov til å utføre handlingene sine. I tilfellene der du selv innhenter data fra eksterne kilder som ikke krever identifisering er det fortsatt viktig å kunne se hvilken tjenestebruker som utførte handlingen.
Ukraina utsatt for cyberangrep: - Vær redd og forvent det verste!
Vi må ta stilling til inputvalidering av informasjonen vi henter eller mottar. Vi ønsker å validere at dataen ikke inneholder skadevare, at den er det den påstår den er, at størrelsen er korrekt og at syntax og verdier er innenfor det vi forventer.
Det skal alltid benyttes sikre, altså krypterte kommunikasjonsprotokoller, både mot eksterne og interne kilder. Det finnes ALDRI en god grunn for å benytte åpne kanaler som for eksempel HTTP. Hvis man ønsker deep-packet-inspection kan man terminere TLS ved et mottak, skanne pakkene og så kryptere igjen for veien videre. Det er fordeler og ulemper med dette også.
Logging kommer til å bli nevnt gjentatte ganger i dette innlegget nettopp fordi det er noe av det viktigste du gjør. Gode logger med meldinger som er lette å parse for et system og forståelig for et menneske med en checksum eller GUID er ønskelig.
Prosessering av data
Når du prosesserer data ønsker du å validere kvaliteten og integriteten av dataene før du sender de videre. Det kan forekomme mellomlagring av filer som senere må slettes på en forsvarlig måte. Man kan også utføre integritetssjekker på data man mottar ved å verifisere de med avsender eller sjekk opp mot andre registre. I tillegg anbefales det å ha et integritetssystem internt som gjør at du kan verifisere at dataene er i tilstandene som du forventer, og har mulighet til å rulle tilbake hvis det har kommet uønskede eller uautoriserte endringer.
Workloadsikring betyr at du sikrer applikasjonene som behandler dataene. Dette innebærer innebygde fail-safe funksjoner, logging og sikkerhetsmekanismer i applikasjonslogikken ut i fra et “defence-in-depth” perspektiv med aktiv monitorering.
Kanskje det viktigste som utføres på dette stadiet er selve klassifiseringen av data. De vanligste kategoriene er:
- Offentlig / Public / Åpen [GRØNN]
- Dette er data som alene ikke innehar sensitiv informasjon på hverken mennesker, systemer, eller virksomheter, ei heller er de nødvendig for systemer klassifisert som kritisk infrastruktur eller virksomhetskritisk.
- Dette er altså data som kan være offentlig tilgjengelig, og anses å ikke kunne gjøre harme for noen som helst parter.
- Eksempler: Hjemmesiden, sosiale medier, kontaktinformasjon.
- Intern / Begrenset [GUL]
- Data som ikke har sensitiv informasjon på hverken mennesker eller systemer, men som kan inneholde informasjon om virksomheten.
- Dataene kan ikke skade personer, men kan ha negativ påvirkning for virksomheten eller samarbeidspartnere til virksomheten.
- Eksempler: Visse typer personinformasjon som ansattnummer, arbeidsdokumenter og kontrakter.
- Sensitiv / Fortrolig [ORANGE]
- Data som inneholder personinformasjon eller annen sensitiv informasjon som kan forårsake skade på virksomheten, personer eller tredjeparter hvis den kommer på avveie.
- Eksempler er sensitive personopplysninger som økonomisk informasjon, helsedata, politisk ståsted, etnisk opprinnelse og seksuell legning.
- Liv og Død / Kritisk Infrastruktur / Strengt Fortrolig [RØD]
- Data som inneholder informasjon eller er kritiske for funksjonaliteten til systemer klassifisert som kritisk infrastruktur, setter liv og helse til grupper eller enkeltindivider i fare og data med høy økonomisk verdi.
- Eksempler: Statshemmeligheter, kode 7 personer og konfidensiell forskningsdata.
Datalagring
Datalagring innebærer lagring av data du aktivt jobber med, data i backup og hvor disse dataene fysisk lagres. Dette innebærer å vite hvor data befinner seg fysisk on-prem, hvor data befinner seg i skyløsninger og backupløsninger og hvilke applikasjoner og mennesker som har tilgang til hvilke data.
Med data lineage ønsker man kartlegging av dataenes opprinnelse, hva som skjedde med dataene (endringer, hvordan de ble brukt) og hvor de flytter seg over tid. Dette hjelper oss med analyser, sikkerhet og feilsøking.
- Angriperne kommer inn, utforsker, ligger lavt, henter ut data, starter kryptering
DLP (Data Loss Prevention) er et komplekst tema og er det et sted det ikke finnes noen form for sølvkule er det her. Mange benytter funksjonaliteter som finnes i brannmurløsninger med merking av data. DLP er vanskelig og krever omfattende metadata-håndtering samt en rekke tekniske kapabiliteter i nettverk og applikasjonslaget. Målet er å hele tiden vite hvor data befinner seg, ha kontroll på hvem som bruker den og har tilgang til den, og viktigst av alt; ha automatiserte prosesser som hindrer at data kommer på avveie og dermed kan hindre uautorisert tilgang. Som du skjønner henger dette mye sammen med tilgangsstyringssystemer og monitorering.
Backup og restore er noen man bør øve på jevnlig, samt ha rutinemessige sjekker av backup data som validerer at den ikke er korrupt (data er manipulert eller ødelagt).
Databruk
Databruk omhandler hvordan mennesker eller systemer jobber med dataene vi eier eller behandler på vegne av andre. Med GDPR har det kommet strenge regler til hva du har lov til å gjøre med data som omhandler individer. For eksempel kan det hende du har en lovhjemmel for å bruke data i produksjon til et gitt formål, men du har sannsynligvis ikke lov til å bruke det samme datasettet til systemutvikling eller testing. Da kan det hende du må minimere (f.eks. attribute suppression), maskere, pseudonymisere, eller anonymisere datasettet. I mange tilfeller vil ikke det være godt nok og du må ty til å mocke data eller ta i bruk syntetiske datasett.
Hvis mennesker skal ha tilgang til eller bearbeide data (eventuelt tilgang til systemer som bruker sensitive data) som inneholder fortrolig eller strengt fortrolig informasjon kan det være krav om PAM (Priveleged Access Management). PAM gir deg full sporbarhet på hvem som gjør hva til hvilken tid. Dette innebærer ikke bare logging av spørringer og handlinger, men inkluderer aktiv monitorering og at sesjonene dine kan bli spilt inn. I systemer med høyeste kritikalitet kan det kreve at operasjonene gjøres fra spesifikke systemer sikret i fysiske bygg med inngangskontroll, videoovervåkning og at det alltid må være flere personer tilstede.
UX-sikkerhet går ut på å sikre brukeren mot seg selv. Her skal brukeropplevelsen være så god og oversiktlig at den gjør det helt klart for brukeren hva den kan og ikke kan utføre av handlinger. Det skal også ligge til rette fail-safe mekanismer som forhindrer misbruk av systemet enten frivillig eller ufrivillig. Og som alltid; alt skal logges.
Dataarkivering
Dataarkivering har noe til felles med datalagring i den grad at vi er interessert i å vite hvor dataene lagres. Men denne biten har også en rekke unike problemstillinger når det kommer til sikring av data med sensitiv informasjon.
Som alltid må lovhjemler være på plass, vi må benytte krypterte kommunikasjonsprotokoller og ha tilgangsstyring på både forberedelsene til arkivering og selve arkiveringen.
Hacker-knepene du bør vite om i 2022: SQL injection, XXE, XXS og SSRF
To utfordringer man fort kan få med arkivering er krypteringsnøkler. Arkivert data skal potensielt ligge lenge. Hvis man krypterer de arkiverte dataene og så benytter et sertifikat til å kryptere nøkkelen må også sertifikatet ha en levetid som gjør at du kan åpne arkivet igjen. Så lang levetid har sertifikater sjelden, og da må man ha på plass rutiner som rekrypterer arkivnøklene med aktive sertifikater. Eventuelt kan man kryptere bare med symmetriske nøkler, men det blir fort mange nøkler å sikre ettersom de da må lagres separat fra arkivet.
Andre problemstillinger man kan komme over er når det ligger persondata i backup. Hvis du da ikke lenger har grunnlag for å ha data om et individ så kan det komme krav om at du skal slette all informasjon du har om vedkommende. Ikke alltid like enkelt ettersom mange har lenge vært dårlige på å spore dataene sine i backupsystemer og har svært få automatiserte funksjoner som kan utføre slike handlinger.
Arkivering av data krever en solid PKI eller kjøpte tjenester som kan levere god nok sikkerhet og forutsigbarhet.
Sletting av data
Dette er kanskje det vi er dårligst på i dag. Det å slette data vil for mange føles feil. Men det er flere gode grunner til å slette data. Hvis ikke du har lovhjemmel for å oppbevare dataen må den slettes. Hvis du ikke har godkjenning fra individet om å bruke deres data må den slettes (gjelder som oftest private virksomheter). Det kan være slik at avtalen mellom din virksomhet og kunden er utløpt eller at du har fått innformasjonen som del av annen data du mottok eller innhentet.
Det kan være behov for fysisk overskriving av gamle harddisker eller fysisk destruering. For SSD disker vil det være behov for sistnevnte (med mindre du har benyttet full disk kryptering som for ekempel. BitLocker). Igjen er det viktig å vite hvor alle data ligger slik at du vet at du har slettet alt i henhold til lover. En utfordring kan være data som ligger i aggregerte datasett i datavarehus og lignende.
Monitorering
Hvordan vet vi at vi har gjort nok for å drive forsvarlig datastyring? Hvis man har klart å få på plass alle nødvendige kapabiliteter nevnt ovenfor, inkludert de som ikke er nevnt eller glemt, så trenger man en måte å bevise dette på. Dette gjør vi med monitorering. Det er derfor logging er så viktig i alle stegene vi har vært gjennom. Data Lifecycle Management skal eksistere rundt tilgangsstyring og sanntidsmonitorering.
Mener studenter lærer for lite om sikkerhet - UiS og NTNU slår tilbake
Monitorering (overvåkning) er at du hele tiden følger med på hva som skjer med dataene dine slik at du kan handle raskt når noe uventet skjer. Vi trenger også å vite hva som fungerer og hva som ikke fungerer godt nok av de andre sikkerhetskapabilitetene som skal levere den ønskede funksjonaliteten. Vi må vite om vi gjør akkurat nok, for lite eller for mye, og om vi bruker for mye eller for lite penger. Hvordan påvirker alle disse funksjonene det daglige arbeidet? Og viktigst av alt så ønsker vi å kunne bevise for tilsynsorganer og kunder at vi gjør det de forventer og krever når vi har tatt på oss ansvaret å behandle deres data. Vi ønsker monitorering av følgende (men ikke begrenset til):
Datakvalitet
- Kompletthet
- Nøyaktighet
- Dupliseringer
- Samsvar med lover/hjemler osv
Data Lineage
- Transformasjoner
- Metadata
- Kvalitetstest resultater
- Referansedata
- Brukere
Ytelse
- Status
- Optimal bruk
- Rapportering av bruk
- Får vi det vi forventer av dataene?
Sikkerhet
- Hendelser og varslinger
- Nettverkshendelser
- Server og applikasjonslogger
- Patch status og sårbarhetshåndtering
- Endepunktslogger
- Tilgangsstyringslogger
- Databevegelser og datatap
Samsvar
- Lovhjemler
- GDPR
- Virksomhetskrav
- Standarder
Data governance er et massivt tema og krever dyp kompetanse fra en rekke forskjellige fagdisipliner. Det krever implementeringer av metodikker og tekniske kapabiliteter i infrastrukturen din. Og da har vi har ikke en gang snakket om hvordan jobbe med dataene slik at de støtter opp under forretningsmodellen eller samfunnsoppgaven din.
Dette er ikke enkelt og det er ikke billig, men det er nødvendig.