Hvordan forebygge eksponering av sensitive data?

Hva er sensitive personopplysninger?

Om man følger GDPR regnes sensitive personopplysninger informasjon om:

• rasemessig eller etnisk bakgrunn
• politisk, filosofisk eller religiøs oppfatning
• at en person har vært mistenkt, siktet, tiltalt eller dømt for en straffbar handling
• helseforhold
• seksuelle forhold
• medlemskap i fagforeninger

Annen sensitiv informasjon som trenger gode sikkerhetsrutiner er blant annet informasjon om konkurranseforhold, regnskapsopplysninger, anbudsdokumenter, fakturaer, kundelister, kundenumre, fakturadato, fakturanummer og ordrenummer.

Hva er sensitive data exposure?

Sensitive data exposure oppstår når en applikasjon, et selskap eller en annen enhet ved et uhell avslører sensitive data ved å ikke beskytte en database tilstrekkelig der informasjonen lagres. Dette kan være et resultat av enten svak kryptering, ingen kryptering eller programvarefeil.

La oss se på noen eksempler:

Webapplikasjon med flere nettsider og databaser

Du har en bruker som vil ha tilgang til en webapplikasjon. Denne webapplikasjonen har flere nettsider og flere databaser. Noen av nettsidene som denne webappen består av bruker kryptering som TLS eller SSL, mens noen av dem bruker bare HTTP. Men til og med nettsidene som bruker kryptering bruker såkalte ‘weak ciphers’. ‘Weak ciphers’, eller svak kryptering, gjør det mulig for hackere å bruke verktøy for å brute-force tilkoblingen som brukeren har mot en webside fra TLS til HTTP, og dermed eksponere sensitive data som er lagret der.

Databasekryptering av kredittkortnumre

Et program krypterer kredittkortnumre i en database ved hjelp av automatisk databasekryptering. Det medfører hel databasekryptering som bruker fullstendig on-the-fly dynamisk kryptering og dekryptering og dataene dekrypteres automatisk når de hentes via en SQL-spørring. Dette oppsettet åpner muligheten for å angripe databasen med SQL-injeksjon for å hente ut kredittkortnumre i klartekst og eksponere det for angriperen.

Bruk av hash-funksjoner for å lagre sensitive data

Man kan bruke usaltet eller enkel hash for å lagre sensitive data. En database bestående av passord bruker usaltet eller enkel hash for å lagre alle passordene. På grunn av en feil i filopplastingen i applikasjonen får en angriper tilgang til databasen. De usaltede hashene man så har fått tilgang til kan eksponeres med et såkalt ‘rainbow table’, med forhåndsberegnet hash, og eksponere passordene for angriperen. Hash generert av enkle eller raske hash-funksjoner kan knekkes av GPUer, selv om de er saltet.

Offentlige repositories i GitHub

Milliarder av kodelinjer er hostet i GitHub for å enklere kunne samarbeide om prosjekter. GitHub har offentlige og private repositories. Tenk deg et tilfelle der en utvikler har lastet opp en SQL-database for et nettsted i et GitHub repository, men har glemt å gjøre det privat. SQL-dataene er nå synlige for offentligheten og en angriper kan utnytte databasen til det aktuelle programmet. For å gjøre dette har angripere tilgang til ulike verktøy som Git Grabber, Git Hound og Git Rob for å nevne noen, men det kan også gjøres manuelt ved å bruke flere filtre.

Hvordan skiller data exposure seg fra et data breach?

Data breach, eller databrudd, er en sikkerhetshendelse der informasjon er gjort tilgjengelig uten autorisasjon. Hackere søker etter data for å kunne eksempelvis stjele penger, kompromittere identiteter eller selge informasjon over ‘the dark web’.

Data exposure er når data blir eksponert i en database eller på en server som alle kan se. Sensitive data kan eksponeres når konfigurasjonsdetaljer for systemer og applikasjoner blir liggende usikret på nettet.

Hvilke angrep kan eksponere sensitive data?

Det finnes forskjellige typer applikasjonsangrep som kan avsløre sensitive data. Noen av disse er listet her:

• SQL Injection Attacks
• Network Compromise
• Broken Access Control Attacks
• Ransomware Attacks
• Phishing Attacks
• Insider Threat Attacks

Kjenn dataene dine godt

Før du kan sikre dataene dine, må du forstå dem: hvordan du samler dem, hvor du oppbevarer dem og hvordan du flytter dem rundt. Du må også definere hvilke data som anses som sensitive, noe som kan være vanskelig selv for små organisasjoner og utrolig utfordrende for store. Når du gjør det, må du huske skillet mellom ulike typer sensitive data du har:

• data du samler inn, for eksempel personlige eller økonomiske data fra kunder
• data som brukes for å få tilgang til andre data, for eksempel brukernavn og passord
• informasjon om systemene dine som potensielt kan brukes av en angriper, for eksempel brukerveiledninger for tekniske applikasjoner eller programvareversjoner

Å forstå dataene dine bør være noe som jobbes med kontinuerlig over tid, og bør ikke anses som et kortsiktig prosjekt eller krav. En liten organisasjon som arbeider på en begrenset plattform kan kanskje ha en god idè om hvor og hva dataene er på et gitt tidspunkt, men det kan være komplisert for et større selskap å ha fullstendig oversikt. 

Les mer: Hva innebærer en moderne dataplattform?

Hvordan gjøre sensitive data mer sikre?

• Du bør klassifisere data som behandles, lagres eller overføres av en applikasjon. Identifiser hvilke data som er sensitive i henhold til personvernlover, regulatoriske krav eller forretningsbehov.
• Bruk tilgangskontroll på disse dataene i henhold til klassifiseringen.
• Ikke lagre sensitive data unødvendig. Slett det så snart som mulig, eller bruk PCI DSS-kompatibel tokenisering. Data som ikke er lagret, kan ikke stjeles.
• Sørg for å kryptere alle sensitive data som er i ro.
• Forsikre deg om at alle krypteringsalgoritmer er de nyeste og sterkeste, og at tilhørende protokoller og nøkler er på plass. Bruk riktig nøkkeladministrasjon.
• Deaktiver hurtigbufring for svar som inneholder sensitive data.
• Krypter alle data i transitt med sikre protokoller som TLS kombinert med ‘perfect forward secrecy’ -koder, krypteringsprioritering av serveren og sikre parametere. Håndhev kryptering ved hjelp av direktiver som HTTP Strict Transport Security (HSTS).
• Kontroller uavhengig effektiviteten av konfigurasjon og innstillinger.
• Lagre passord med sterke, adaptive og saltede hashingfunksjoner med en ‘key derivation function’, som for eksempel:
  • Argon2
  • scrypt
  • bcrypy
  • PBFKDF2

Avslutningsvis ønsker jeg å ta en titt på en tegneserie fra XDCD. Dette er en interessant tegneserie fordi vi ofte kan lure oss selv til å tro at vi har en sikker mekanisme, men i dette tilfellet er det bare en triviell øvelse for å komme tilbake til de opprinnelige dataene.