Det som skjer i skyen, blir i skyen?

hendelseriskyenPå Dataforeningen/CSA Norges nettverksmøte i Trondheim 16. september presenterte jeg noen tanker om håndtering av sikkerhetshendelser i nettskyen. Hva er det som skiller skyen fra annen tjenesteutsetting når det smeller?

Utgangspunktet vårt er at det går ikke an å lage et datasystem som er 100% sikkert. Dette betyr at hvis det er noen som ser verdien av å bryte seg inn i dine systemer, så kommer de til slutt til å lykkes – og du må derfor gå ut i fra at informasjonssikkerhetshendelser kommer til å skje i ditt system.

Vi har tidligere argumentert at spesielt for små og mellomstore bedrifter vil det vanligvis innebære en sikkerhetsforbedring å flytte bedriftens systemer til skyen, ettersom man da kan få en leverandør med dedikert sikkerhetspersonell som er tilgjengelig 24/7, kontra en deltids systemansvarlig som i tillegg fungerer som helpdesk, vaktmester, og minibuss-sjåfør.

På den annen side er håndtering av hendelser i skyen vanskelig fordi det oftest er stor avstand (fysisk og logisk) til leverandøren, og følgelig vanskelig å involvere leverandøren når noe skjer. Dette betyr også at man ikke uten videre har tilgang til fysiske bevis (forensics); skyløsninger er ofte basert på “trangboddhet” (multi-tenancy), noe som medfører at data fra flere kunder potensielt kan finnes på en gitt infrastruktur, og det vil ikke være akseptabelt å utlevere f.eks. en rå dump fra en harddisk i dette tilfellet. Det er også uklare juridiske begrensninger når data stammer fra en jurisdiksjon (f.eks. Norge) men lagres i en annen (f.eks. USA). Bildet kompliseres ytterligere av at man potensielt har lange leverandørkjeder (som vist på figuren over, hvor leverandør A bruker tjenester fra leverandør B, som igjen bruker tjenester fra leverandør C).

Det finnes overraskende lite litteratur på dette området. Cloud Security Alliance laget i 2011 rapporten Security Guidance for Critical Areas of Focus in Cloud Computing, denne har et eget kapittel om hendelseshåndtering som dekker mange aspekter av forholdet mellom en nettskyleverandør og en kunde, men den tar ikke høyde for at tjenesten kan være levert som en del av en kjede. I 2010 publiserte Grobauer og Schreck artikkelen “Towards incident handling in the cloud: challenges and approaches“, hvor de (som tittelen indikerer) identifiserer mange utfordringer, men egentlig få ferdige løsninger. Såvidt jeg har klart å bringe på det rene har ingen gjort noen forsøk på å følge opp dette arbeidet i de fire årene som har gått. De mest kjente “standardtekstene” for hendelseshåndtering (ISO/IEC 27035, NIST SP 800-61, ENIS27035A Good Practice Guide for Incident Management) dekker ikke nettskyen spesielt, selv det er mye som er overførbart.

Vi liker å forholde oss til ISO/IEC 27035’s fem faser i hendelseshåndtering, som illustrert på figuren til venstre. I det følgende skal vi ta for oss fasene en for en, og peke på noen anbefalinger.

Plan

I planleggingsfasen er det viktig å bringe på det rene hvor dataene faktisk ligger lagret, og hvordan leverandørkjeden ser ut. Dernest er det avgjørende at du faktisk har en hendelseshåndteringsplan! Sørg for å dele planen med involverte aktører, og forsikre deg om at alle aktørene er enige om ansvarsfordelingen (eventuelt korriger planen). Dette betyr også at SLAer må ha med klausuler for hendelseshåndtering.

Detect

Hva finnes av datakilder for å detektere angrep? Det er mulig at leverandøren kan bistå med tidlig varsling, enten via informasjon om angrep på andre, eller med informasjon om angrep under oppseiling mot egen infrastruktur. Noen leverandører tilbyr også inntrengningsdeteksjons-tjenester (IDS).

Assess

I vurderingsfasen er tilgang på informasjon nøkkelen! “Øyeblikksbilder” av virtuelle maskiner (VM “snapshot”) kan gi gode muligheter for analyse; man kan starte og stoppe, starte på nytt, inspisere minnet, etc. I planleggingsfasen bør man også ha klarlagt hvilken “forensic support” man kan regne med fra leverandøren. Dette omfatter oversikt over hva leverandøren logger, om loggene er beskyttet mot modifikasjon, og fundamentale ting som om klokker i systemet er synkroniserte.

Respond

I denne fasen finner du ut om planene dine fungerer! Som tidligere nevnt kan virtuelle maskiner fryses, stoppes, restartes; dette gjør at man på en måte “har råd” til å gjøre litt mer brutale ting enn man kanskje ville tørre å gjøre på en konvensjonell server. Det går også an å utnytte egenskapene til skyen direkte, f.eks. ved et tjenestenektangrep (DoS) kan man teoretisk pøse på med nye instanser; eventuelt kan man flytte tjenesten til en ny sky ved migrering.

Learn

I læringsfasen er det tid for å oppsummere; hva fungerte bra, og hva fungerte dårlig? Stemte planene med virkeligheten? Her er det svært nyttig å lage en ordentlig rapport, og dele med alle involverte. Rapporten bør inneholde en tidslinje av hendelsen, med analyse og identifikasjon av rot-årsaken(e). Beskriv også de kortsiktige tiltakene som ble iverksatt for håndtering og gjenoppretting, samt anbefalinger for langsiktige tiltak.

Tilbake til eksempelet

incident-chainEn av mange ting som litteraturen identifiserer som en mangel, er informasjonsdeling langs hele leverandørkjeden. I eksempelet vi innledet med har vi altså situasjonen som illustreres igjen til høyre, der en bruker må forholde seg til leverandørkjeden A-B-C. Vi trenger derfor en mekanisme hvor leverandør C kan informere B om hendelser som påvirker tjenesten B kjøper fra C. B må da aggregere denne informasjonen (og annen informasjon), og gjøre den tilgjengelig for A, som må gjøre det samme ovenfor sluttbrukeren. Det er sannsynlig at grensesnittet mot sluttbrukeren må bli ganske annerledes, og må kanskje involvere manuell behandling.

Vi har identifisert et utvalg protokoller som kan være kandidater for kommunikasjon mellom leverandører:

  • Intrusion Detection Message Exchange Format (IDMEF)
  • Incident Object Description Exchange Format (IODEF)
  • CSA Cloud Trust Protocol (CTP)
  • Transparency Log (TL)

Vi jobber videre med denne problemstillingen i prosjektet A4Cloud, og kommer snart tilbake med flere resultater!