Hvordan sikre workloads i skyen?

Hva er en workload? 

En workload er en operasjon som tar i bruk skyressurser for å utføre en jobb. Dette innebærer alle elementer som kjører hos en skyleverandør hvor det utføres en eller flere oppgaver i kontekst av din virksomhet. 

Vi kan dele det opp i to abstrakte grupper for å forenkle bildet. Det ene er selve tjenesten og det andre er infrastrukturen som får tjenesten til å utføre sin jobb. Hvor ansvaret for tjeneste og underliggende infrastruktur starter og slutter er helt opp til hvilken modell du kjøper fra skyleverandøren. Uansett hvilken modell du benytter så er sikkerheten et delt ansvar mellom deg og skyleverandøren. En grov forenkling av oppdelingen er:

Tjeneste og Konfigurasjon er “unikt” for din virksomhet, mens skyleverandørn har ansvaret for at sine underliggende tilbydte tjenester er forsvarlig sikret. Tjenesten er hvor vi finner applikasjonsloggikken. Konfigurasjonslaget er hvordan din virksomhet har koblet sammen tilbydte tjenester fra skyleverandøren og konfigurert de for å støtte opp under tjenesten. Sammen kalles dette en workload, ettersom alle delene er nødvendig for at tjenesten skal få utført sin oppgave.

Ansvarsområdene kan virke enkle. Du har ansvaret for Tjeneste og Konfigurasjon, mens skyleverandøren har ansvaret for sine tjenester. Men det er ikke skyleverandørens ansvar at du benytter deres tjenester på en sikker og forsvarlig måte enten bevisst eller ubevisst. De fleste skyleverandørene har et hav av muligheter i sine biosfærer, og det er ikke alltid enkelt å lære hvordan de enkelte komponentene fungerer i dybden eller spiller sammen. 

Hvis man benytter hybrid-løsninger (on-prem + sky) eller multi-cloud (to eller fler forskjellige skyleverandører) eller multi-hybrid (on-prem + to eller flere skyleverandører) så forstår man fort at her gjelder det å ha tunga i rett munn.

Hvilke trusler går mot workloads?

Man har ikke færre trusler enn før når man hopper til skyen. Tvert i mot, man har fått flere. Fordelen med å gå til skyen er at risikoen rundt de gamle truslene ofte er lavere. Det betyr dog ikke at vi ikke trenger en strategi med tydelig kommuniserte retningslinjer for sikkerhet når vi jobber i skybaserte miljøer. 

Applikasjonssikkerhet

Hvis du utvikler egne løsninger som produksjonssetter i skyen så har du akkurat samme sikkerhetsansvar som du hadde når du deployerte de på gamle on-prem datasenteret. Skyen kan levere flere støtteverktøy som du ellers aldri hadde implementert, men disse verktøyene er omliggende tjenester og ikke noe som gjør din applikasjonslogikk og kode noe bedre. 

Konfigurasjonsstyring

Dette er kanskje området som ikke er så mye bedre enn det var på gamle on-prem, snarere tvert i mot. Når vi kludret det til i “gamle dager” kunne vi kanskje spise lunch før vi fiksa feilen fordi det lå i en “sikker” sone som var godt segregert fra internett. Skyplattformer har også segregering, men hele poenget med skyen er at den skal kunne nåes fra eksterne endepunkter, inkludert de som skal konfigurere og styre den.

Skyen bringer også med seg økt kompleksitet og mange nye ting og trykke og vri på. Det er ikke alltid enkelt å vite hva som spiller bra sammen og hva som overhodet ikke spiller bra sammen. Bare IAM løsningene alene har med seg hundrevis av roller som kan strupes ned, låses opp eller kombineres. Feilkonfigurering for roller og tjenester var årsaken til at en bank fikk en rekke data kompromittert i 2019. 

Brukerkontoer

Brukerkontoer er nøkler inn til skyplattformene og det gjør de til naturlige mål for de mange forskjellige Phishing angrep som finnes der ute. Passordrutiner, multi-faktor autentisering, gode strategier rundt tilgangsstyring bygd ut i fra least-privilege og separation of duty har aldri vært viktigere.  

Verdikjedeangrep

En av de mest populære angrepsvektorene de siste årene har vært å gå etter komponenter i verdikjeden. Dette er potensielt også et område hvor risikoflaten øker når man går til skyen. Ikke nok med at man må håpe at sine egne verdikjeder er sikret, men mange av tjenestene som tilbys fra skyleverandører er direkte eller indirekte bygd på eksisterende programvare som ikke skyleverandøren har utviklet selv. 

Endepunktsikkerhet

Alle som jobber i og med skytjenester jobber fra mange forskjellige enheter som bærbare eller stasjonære maskiner, nettbrett, smarttelefoner og noen ganger IoT enheter. Det gjør alle disse enhetene til lukrative målskiver for angripere, ettersom en kompromittert enhet sannsynligvis vil gi brukerkontoer eller i hvert fall et sterkere fotfeste for videre eskalerende angrep. 

Utro tjener

Mangler man en gjennomtenkt brukerstyring eller man velger useriøse partnere så vil utro tjenerere både hos deg eller skyleverandøren kunne utføre uønskede handlinger.

Hvordan sikre workloads i skyen? 

De fleste som jobber med utvikling av IT løsninger i dag har et forhold til testing og sikkerhet i selve applikasjonene. Dette er noe vi har lært på den smertelige og dyre måten. Og når noe begynner å koste for mye kommer man opp med strategier og prosesser for å redusere usikkerhet og kostnader. Det er nettopp dette vi også trenger for arbeidslastene vi kjører i skyene. Noen kan spørre seg hvorfor man bruker dette uttrykket “Workload security” og det er for å minne oss på at sikkerheten i disse domenene ikke begynner og stopper ved applikasjonen. Vi trenger en sikkerhetsstrategi som adresserer alle trusselområdene.

Applikasjonssikkerhet

• Baseline sikkerhet. 
  • Vi trenger å kartlegge krav og behov vi har til sikkerhet i applikasjonsutvikling. Hvis ikke vi kan kommunisere en standard for sikkerhetskontrollere som må bakes inn i, og valideres, i utviklingen sil de sannsynligvis ikke bli bakt inn i løsningen. Vi må kunne fortelle utviklerteamene hva som er minstekrav til alle løsninger, og så må man kartlegge særegne behov for nettopp løsningen under utvikling. Validering av sikkerhetskontrollerne går på å monitorere de for å se om de leverer som forventet, har negativ effekt eller koster mer enn det smaker. Det finnes flere standarder der ute som kan hjelpe oss med å lag en benchmark for vår virksomhet, som OWASP ASVS, OWASP CSVS, NIST SP800-53a+b, eller ISO27002.
    
• Pipeline sikkerhet
  • Bygg og Deploy pipeline skal bestå av et sett med automatiske og manuelle sikkerhetskontrollere som code reviews, enhetstester, negative tester, statiske kode analyser, dynamisk kode analyser, sårbarhets- og avhengighetsscanning, sikkerhetstester og penetrasjonstester, for å nevne noen. 
    
• Sikker Utviklingsmetodikk
  • Uavhengig av hvilken utviklingsmetodikk man bruker så kan man implementere prinsipper fra Sikre Utviklingsmetodikker som Microsft Secure Development Lifecycle eller OWASP Secure Code Development Lifecycle. Her tar man inn viktige sikkerhetsaktiviteter som bidrar til økt bevissthet og kompetanseheving hos utviklerne, samt øker sannsynligheten for at man vil oppdage feil og sikkerhetsbugs tidligere i utviklingsprosessen. 
    
• Trusselmodellering og tekniske ROS analyser
  • Uavhengig om man har aktivt jobber med Sikker Utviklingsmetodikk eller ikke så har det stor påvirkning om utviklerne utfører tekniske trusselmodelleringer og Risiko- og Sårbarhetsanalyser. Dette vil være nyttig i forhold til testing og synliggjøring av sårbare eller sensitive ressurser. 
    
• Security Champion (SC) program
  • Det finnes ingen satt definisjon på hva et Security Champion program bør inneholde, ei heller noe krystallklar definisjon på rollen, men hvis man klarer å utnevne en SC på hvert utviklerteam, legge til grunn et forum for de med rollen og lar de regelmessige få utveksle erfaringer så kan dette bidra til en kraftig kulturendring innenfor sikkerhet, som igjen resulterer i tryggere, og potensielt billigere, applikasjonsportefølje for virksomheten.

Konfigurasjonsstyring

• Zero-Trust
  • Skyen er bygget ut i fra Zero-Trust prinsipper i bunn, men de prinsippene vil neppe bli med helt opp i applikasjonslaget hvis man ikke har et konkret forhold til dette når man konfigurerer sine skymiljøer. Zero-Trust er en av hjørnesteinene for sikring av workloads i skyen. Zero-Trust prinsippet dikterer at det ikke skal finnes inherent-trust noe sted. Alle koblinger skal valideres og monitoreres. Zero-trust er med å sikrer av data, enheter, mennesker, nettverk og arbeidslastene (workdloads). Men for å kunne bygge zero-trust helt opp er vi avhengig av at en rekke andre konfigurasjonsstyringer og strategier er ivaretatt. 
    
• IAM – Identity and Access Management
  • Hvis ikke man ikke har en strategi for hvordan man driver brukerhåndtering og tilgangsstyring i skyen vil man ikke ha mye zero-trust. Det man derimot vil ha mye av er økt sannsynlighet for kompromittering. Moduler kan få feil roller som gir de mulighet til å utføre handlinger man ikke var klar over, eller rollene gir for mye rettigheter. 
    
• Logging, Monitorering og Sporing
  • Ingen Zero-Trust uten monitorering. Man må overvåke applikasjoner og tjenester i skyen, og generere alarmer ved unormale hendelser. Dette gjelder brukerkoblinger og handlinger de utfører. Monitorering av brukere, applikasjoner, nettverk, ressursbruk, etc. vil kunne bidra til å gi indikatorer på sikkerhetsbrudd tidlig. 
    
• MFA – Multi-Faktor Autentisering 
  • Alle menneskelige brukere som jobber på skytjenester skal benytte en form for MFA. 
    
• Kryptering 
  • Alle koblinger fra endepunkter til skytjenester skal være kryptert. Alle koblinger mellom tjenester i skyen skal være kryptert. I tillegg skal all data være kryptert at-rest, og hvis det er mulig, og kritikaliteten på dataene er høy, bør man også vurdere kryptering at-work. 

Brukerhåndtering

• Identity Management Lifecycle
  • Har man både on-prem infrastruktur og en eller flere skyleverandører kan man fort bli svimmel av å tenke på hvem som skal ha tilgang til hva, til hvilken tid, på bakgrunn av hva. Det er ikke nok å bare ha et godt IAM regime i skyen, man trenger en IAM strategi som strekker seg over hele angrepsflaten, og dette bør forvaltes med et Identity Management Lifecycle program med høy grad av automatisering og monitorering. 

Verdikjedeangrep

• Dependency scanning 
  • Det er trivielt å implementere dependency scanning (avhengighetsskannere) i utviklingspipeline, men man kan også trenge det på selve skyplattformen. Man ønsker å vite om sine førsteklassses avhengigheter, men også avhengighetenes avhengigheter. 
    
• Sårbarhetshåndtering
  • Det vil være stunder hvor man oppdager sårbarheter man ikke med en gang kan fikse, eller man anser risikoen som lav og aksepterer den. Disse sårbarhetene/svakhetene må håndteres ved at de katalogiseres og monitoreres. Hvis man må kjøre med svakheten, men også må redusere risiko må man vurdere andre omliggende sikkerhetskontrollere. 
    
• Integritetskontroll
  • For å kunne avdekke endringer på data eller filer, som f.eks. Konfigurasjonsfiler, bør man implementere File Integrity Monitorering. Det bør også være på plass reverseringsjobber som endrer manipulerte filer tilbake til korrekt tilstand. 

Endepunktssikkerhet

• Anti-Virus, Malware scanning og Agenter
  • Angrep mot enkeltpersoner kan skje utenfor virksomhetskontrollerte enheter, og enkeltpersoner har sjelden nok ressurser til å sikre sine egne enheter like godt som virksomhetens sikkerhetsteam. Derfor er det hensiktsmessig at det meste av arbeid mot skyen foregår fra kontrollerte enheter med sikkerhetskontrollere på. 

Utro tjener

• Defense in depth
  • En av de vanskeligste truslene å beskytte seg mot er innsidetrusselen. En utro tjener har allerede tilgang. For å imøtekomme dette trenger man en sikkerhetsstrategi som er bygd etter Defense-in-depth prinsippet. Hvis ikke første sikkerhetsmekanisme klarte å forhindre ondsinnet bruk, så skal den neste slå til, og deretter enda en. Eksempler her er at alle brukere er utstedt med bare nødvendige rettigheter, og hvis brukeren skal utføre handlinger som krever privilegert tilgang kan handlingene monitoreres og spilles inn, generere alarmer ved avviik, oppførselsanalyse, automatiske sperrer som aktiveres ved mistanke om ondsinnede handlinger, etc. Det kan også være behov for å implementere apoteker-prinsippet på visse aktiviteter, som da vil kreve at to ansatte må autentiseres for at handlingen skal kunne gjennomføres. 

Oppsummering

Dette var noen av de overordnede tiltakene man kan vurdere for å sikre sine workloads i skyen, og det finnes flere. Noen av disse er enkle, raske og billige å implementere, mens andre krever omfattende strategier og planlegging. Lykke til med din sikring av skylaster =)