Diensten in de cloud: lees altijd de kleine lettertjes

0

Tegenwoordig is het gebruik van clouddiensten vaste prik bij bedrijven. Veel ondernemingen lijden echter aan tunnelvisie als het op de beveiliging aankomt. Dit blijkt uit de nieuwste versie van de ‘Data Breach Digest’ van Veri­zon. In het rapport worden zestien scenario’s van cyberaanvallen omschreven. In dit artikel het hor­rorverhaal van een anonieme ma­nager ict-beveiliging. Het verhaal is waargebeurd.

Op een late donderdagmiddag was ik op mijn laptop aan het werken. Kort voor mijn vertrek naar huis verdeelde ik mijn aandacht over een paar e-mailberichten en een van mijn favoriete blogs over informatiebeveiliging. Net toen ik mijn laptop in mijn tas wilde stoppen, begon mijn vaste telefoon te rinkelen. Waarschijnlijk iemand die me iets wilde aansmeren. De telefoon stopte met rinkelen en het lampje van de voicemail ging niet branden. Tijd om naar huis te gaan, dacht ik. Maar zodra ik mijn tas over mijn schouder had geslingerd en het kantoor wilde verlaten, ging mijn mobiele telefoon. Het was John, onze chief security officer.

Haperingen

Na een kort gesprek met John werd het me duidelijk dat er sprake was van een beveiligingsincident in onze webwin­kel. Klanten hadden de hele dag onze klantenservice gebeld in verband met dezelfde klacht. Nadat zij hun betalingsgegevens hadden ingevoerd, kregen ze een melding te zien dat de transactie was mislukt en dat ze het opnieuw moesten proberen. Toen ze een nieuwe poging de­ den, werd de transactie naar behoren vol­tooid. Hoewel dit soort haperingen soms voorkomt, kreeg de klantenservice die dag meer dan honderd telefoontjes. Ik vernam dat het financiële team al contact had opgenomen met het bedrijf dat onze betalingen verwerkt. Deze partij gaf aan dat er geen sprake was van een noemens waardig aantal mislukte transacties.

Ik besloot een snelle testtransactie uit te voeren om te zien of ik het probleem met onze webwinkel kon repliceren. Toen de betalingspagina werd weerge­geven en ik werd gevraagd om mijn cre­ditcardgegevens in te voeren, ontdekte ik direct iets vreemds: op de pagina ontbraken de standaard kopteksten, onderschriften en logo’s van ons bedrijf. Het was een volledig kale betalingspa­gina. En beslist niet de onze!

Nieuwsgierig voerde ik dummy­ creditcardgegevens in en klikte ik op de verzendknop. Ik kreeg daarop direct een foutpagina te zien die overeenkwam met de beschrijving van onze klanten. Vervolgens werd ik doorgeleid met het verzoek om het nogmaals te proberen. Dit keer zag de betalingspagina er precies zo uit als die eruit moest zien. Mijn aanvankelijke vermoeden was dat iemand onze webwinkel had geïnfil­treerd en een nagebootste betalingspa­gina had toegevoegd met het doel om de creditcardgegevens van klanten te verza­melen. John en ik waren het erover eens dat we ons incident-respons(IR-)plan in werking moesten stellen en externe hulp moesten inschakelen.

De redirect

Onze aanvankelijke gesprekken met het risicoteam van Verizon waren verhelderend. De leden van het team gaven aan dat ze hetzelfde scenario al diverse malen eerder waren tegengekomen, vooral in Europa en Azië. De redirect (omleiding) naar onze legitieme beta­lingspagina was bedoeld om ervoor te zorgen dat de transactie uiteindelijk met succes werd voltooid, zodat de cyber­ criminelen geen argwaan bij klanten zouden wekken.

Het risicoteam ging meteen aan de slag. Het verzamelde achtergrondinfor­matie over het incident en bracht onze omgeving in kaart. Het team richtte zich vervolgens op onze webwinkel, die voornamelijk klanten in West-Europa be­ diende en werd beheerd door een externe webdeveloper. Een conference call die we voerden met het risicoteam en deze webdeveloper gaf ons een beter begrip van de manier waarop die onze website beheerde. Op basis van deze informatie konden wij een planning maken voor het verzamelen van het benodigde forensi­sche bewijs (zie ook onderaan dit stuk).

Hoewel we op de hoogte waren van het feit dat de webdeveloper actief was in de Europese Unie (de Republiek Tsjechië), wisten we niet dat deze in werkelijkheid gebruikmaakte van de diensten van een goedkope aanbieder van clouddiensten aan de andere kant van de wereld. Toen ik dat vernam, rezen de haren mij te berge. In mijn gedachten hoorde ik onze privacyjurist al vragen: “De gegevens van onze klanten lagen waar opgeslagen?”

Uit de lucht

Het risicoteam stelde voor om de webwin­kel offline te halen om te voorkomen dat er meer klantengegevens werden gestolen terwijl het probeerde te achterhalen hoe de website was geïnfiltreerd en welke herstelmaatregelen we konden nemen. Wij gingen daarmee akkoord. De webdevelo­per haalde de website direct uit de lucht en verving die door een standaardpagina met de tekst “Deze website ondergaat momenteel onderhoud”. En vanaf dat moment be­gon de klok te tikken, omdat onze klanten en de rest van de wereld zich vroeg of laat zouden realiseren dat hier geen sprake was van een normale onderhoudsprocedure.

Misplaatste grap

We waren aanvankelijk van onze externe webdeveloper voor het opzetten van een conference call met alle betrokken partijen, waaronder de cloudprovider in India. We moesten snel logbestanden verzamelen voor het deel van de cloudom­eving dat onze internet- en database­ diensten behuisde, zodat we samen met het risicoteam inzicht konden verwerven in het indringerstraject en het tijdstip van infiltratie. Tijdens de conference call ver­namen we dat de cloudprovider in India onze website samen met de klantengege­vens hoste op systemen die zich fysiek in een datacenter in Maleisië bevonden. Als ik niet persoonlijk bij deze vergaderingen aanwezig was geweest, zou ik gedacht hebben dat iemand een misplaatste grap met me had uitgehaald.

Tegen de tijd dat onze externe web­developer de cloudprovider in India bij het gesprek had betrokken (die er vervolgens de datacentermanager in Maleisië bij haalde), waren er al twee weken voorbijgegaan. Gelukkig was de webwinkel in die periode offline, zodat er geen klantengegevens meer konden worden gestolen. Tegelijkertijd voelden we echter ook de pijn van een webwin­kel die een halve maand geen geld in het laatje bracht, plus de negatieve gevol­gen voor ons bedrijfsimago.

Gelukkig beschikte het risicoteam over lokale onderzoekers en kon het een mobiel laboratorium op locatie inrichten, zodat het digitale forensische onderzoek snel van start kon gaan. Ze moesten echter nog altijd enkele obstakels uit de weg ruimen in verband met de multitenant­ omgeving van de cloudprovider en de bescherming van de data van zijn andere klanten. Het risicoteam wist daar echter snel werk van te maken. Ze hadden vaker met het bijltje gehakt.

Wit-Rusland

Gewapend met het benodigde bewijs­materiaal was het risicoteam in staat om snel onze vermoedens te bevestigen. Een cybercrimineel had een valse betalings­pagina gebouwd die aan onze klanten werd gepresenteerd met het doel om hun creditcardgegevens vast te leggen. Nadat deze informatie was verzameld, werden ze doorgeleid naar onze legitieme betalingspagina, zodat de transactie naar behoren kon worden voltooid.

Uit het digitale bewijsmateriaal bleek verder dat de vervalste betalingspagina was gepro­grammeerd om de verzamelde credit­cardgegevens in real time via het secure hypertext transfer protocol (HTTPS) te uploaden naar een extern IP-adres in Wit-Rusland. Gelukkig kon het risicoteam dankzij een grondige analyse van de code van de cybercrimineel vaststel­len dat er sprake was van een fundamen­tele fout in de procedure voor het opzet­ten van een externe verbinding. Toen de logbestanden van het netwerk erop werden nageslagen, bleek dat het niet was gelukt om de creditcardgegevens weg te sluizen. Eindelijk goed nieuws!

Geleerde lessen

We beseffen nu hoe belangrijk het is om te weten waar onze gegevens zich bevinden. De medewerkers van het risicoteam vertelden mij dat ze maar al te vaak merken dat organisaties er moeite mee hebben om bedrijfsactiva en data binnen hun eigen omgevingen effectief in kaart te brengen. Nog minder organisaties we­ ten hoe het met de opslag van hun data in omgevingen van derden is geregeld.

De keten van relaties met onderaanne­mers kan ertoe leiden dat een organisatie niet precies weet welke rechtspersonen de gegevens van hun klanten in bezit hebben. Dit probleem kan worden verer­gerd als deze externe partijen onvol­doende weten van informatiebeveiliging, gegevenssoevereiniteit en beperkingen die gelden ten aanzien van grensover­schrijdend dataverkeer. Zoals uit dit specifieke incident blijkt, zijn dit soort complicaties van invloed op de tijd die nodig is voor het uitvoeren van grondig digitaal forensisch onderzoek.

Veel IR-teams en cloudproviders wor­stelen met het verzamelen van specifiek bewijsmateriaal binnen multi-tenant­ cloudomgevingen die gegevens van uiteenlopende klanten beheren. Dit kan een uitgebreide analyse van de werkelijke oorzaak belemmeren, of zelfs onmogelijk maken. Dat zal voor veel organisaties als een trap na voelen. Ga dus altijd na of dienstverleners over een architectuur beschikken die ondersteuning biedt voor audits en onderzoek door externe partijen.

Vijf uitdagingen van foren­sisch onderzoek in de cloud

Traditionele taken die verband houden met digitaal forensisch onderzoek, zoals het analyseren van het geheugen, schijven en netwerkgegevens, worden aanzienlijk bemoeilijkt als de onderzoekers geen fysieke toegang tot systemen hebben.

Bedrijven realiseren zich pas dat er sprake is van contractu­ele of technische beperkingen van toegang tot ‘hun servers’ bij een cloudprovider zodra er een beveiligingsincident optreedt. Daarom is het van cruciaal belang om ervoor te zorgen dat je organisatie klaar is om op dergelijke incidenten te reageren.

Met het oog op de extra complexiteit die gepaard gaat met managed services en clouddiensten van derden is het belangrijk om jezelf de volgende vragen te stellen:

  1. Beschikken we over tools voor het verzamelen van forensisch bewijsmateriaal voor uitbestede en extern gehoste systemen?
  2. Is er sprake van beperkingen van de toegang die we hebben (dat wil zeggen kunnen we alleen logische bestanden opvragen en moeten we het dan zonder verwijderde gege­ vens stellen)? Zijn we über­haupt in staat om toegang tot onze data te krijgen?
  3. Hoe snel kunnen we toegang tot de data krijgen? Welke technische beperkingen gelden er voor de externe locatie (bijvoorbeeld langzame overdrachtssnelheden)?
  4. Zijn dienstverleners contractueel verplicht om assistentie te verlenen in het geval van een incident (oftewel: heb je de kleine lettertjes ge­lezen?) En zo ja, welk service­niveau en welke respons zijn zij verplicht te bieden?
  5. Welk type loggegevens bewaart mijn dienstverlener en hoelang?