Cloud computing is een nieuwe methode (of wellicht: hype) voor het leveren van computer resources aan klanten, maar het is geen nieuwe technologie. Ook de benodigde functionele security controles zijn niet verschillend van de bestaande en gebruikte security tooling.
Cloud computing is geen nieuwe technologie en de benodigde functionele security controles zijn niet verschillend van de bestaande en gebruikte security tooling. Er zij n echter wel productaanpassingen en -ontwikkelingen om een optimale efficiënte bescherming te bieden in deze (virtuele) infrastructuur. De additionele security vraagstukken zijn in principe niet verschillend van de huidige hosting en outsourcing modellen. Ervaring is er dus ook al.
Hoe zit dat eruit?
Er zijn drie functie categorieën in cloud computing:
– Software-as-a-Service (Saas). Voorbeeld: Salesforce.com, Hotmail en Google Docs.
– Platform-as-a-Service (PaaS). Voorbeelden: Microsoft Azure, Force en Google App engine.
– Infrastructuur-as-a-Service. Voorbeelden Amazon EC2 en S3, Terremark Enterprise Cloud en Windows Live Skydrive.
Clouds kunnen daarnaast ook fysiek verdeeld worden in public, private of hybride cloud en een paar afgeleide zoals community of shared cloud.
Zoals gesuggereerd zijn de functionele security controles in cloud computing voor het grootste gedeelte niet anders dan de controles in elke it-omgeving. We vinden ‘gewoon' nog steeds de Firewall (traditioneel en voor virtualisatie), IPS of Patch Management (traditioneel en voor virtualisatie), Antimalware (voor virtualisatie), netwerk segmentatie, 2-factor authenticatie, Identity and Access Management, data encryptie (binnen de guest in een virtuele omgeving) en vulnerability testing of scanning. Er is wel een accentverschuiving te zien naar Identity and Acces Management en data integriteit.
Door het gebruik van cloud service modellen, creëren de operationele activiteiten met technologieën die hieraan onderliggend zijn, andere risico's voor een organisatie dan binnen traditionele it-netwerk omgevingen. Cloud computing is voor de afnemer het uit handen geven van directe controle maar niet van de aansprakelijkheid, ook al vervalt de operationele verantwoordelijkheid naar een derde partij.
Het verschil tussen de operationele en uiteindelijke verantwoordelijkheid zal men willen oplossen door het sluiten van waterdichte security sla's en de aanwezige en beschreven security controles. De controle op de geleverde security, vastgelegd in deze sla's, zal door middel van externe en interne audits uitgevoerd worden.
De houding van zowel een cloud provider en de klant word gekarakteriseerd door de volwassenheid, effectiviteit en compleetheid van de geïmplementeerde security controles. Deze controles zijn geïmplementeerd in meerdere lagen: van de fysieke security naar netwerk en it-systemen. Daarnaast zijn er controles nodig op gebied van organisatie, personeel en processen, zoals het scheiden van functie- en changemanagement. De security verantwoordelijkheden van de provider en klant verschillen tussen de verschillende service modellen.
In IaaS modellen kunnen de providers alleen de fysieke security en virtualisatie security managen. De (operationele) security van de besturingssystemen, applicaties en data is aan de klant zelf.
Bij een SaaS model zal de provider echter ook de verantwoordelijkheid moeten dragen van security management op de infrastructuur, de applicaties en data. De klant zal hierbij minder operationele verantwoordelijkheid dragen.
Afhankelijk van de huidige stand van zaken van het niveau van de security van de klant en de keuze van het cloud-model kan de efficiëntie van de totale security op het gebied van controles verbeteren. Deze verbetering is een serieuze opmerking omdat er bij veel organisaties nog wel wat aan schort en de provider snel een schaalbaarheidsvoordeel heeft, waardoor sommige exotischer beveiligingstooling wellicht toegankelijk wordt. De klant hoeft zich voornamelijk bezig te houden met controle op de nageleefde 'Security'' Level Agreements.
We zien op dit gebied een toename in vragen rond de tool vulnerability scanning als een audit/compliance tool. Een toename ten opzichte van de huidige vraag rond hosting en outsourcing situaties.
Als client heb je geen controle over de onderliggende hardware en hypervisor.
Je bent wel aansprakelijk.
Een virtuele infrastructuur, service of applicatie is zo veilig als de hardware en hypervisor waar op of onder deze draait.
Daar zou ik wel rekening mee houden als het gaat om risicobeoordeling en mitigatie.
De term “Cloud” in het algemeen is te breed om één passende security oplossing voor te bieden. Het is belangrijker te kijken naar welke vorm van cloud er gebruikt wordt, en hier een passende oplossing voor verzinnen. Bij hosted services als e-mail en dergelijke is het niet zozeer meer noodzakelijk om de e-mail server zelf te beveiligen, maar de mail al bij binnenkomst van het netwerk te scannen.
Als er gebruik gemaakt wordt van hosted servers (virtueel), dan hebben deze hetzelfde soort beveiliging nodig als de traditionele server (Afgezien van de ontwikkelingen op het gebied van Hypervisors). Het enige verschil is dan vaak dat je de beveiliging door middel van een SLA uitbesteed aan iemand anders. Het voordeel hiervan is dat het de verantwoordelijkheid is van iemand in de cloud. Het nadeel is dat het de verantwoordelijkheid is van iemand in de cloud. En gelijk daar zit het grootste security / privacy risico. Want waar IS die data, en wie kan daarbij? In mijn blog http://spicynienke.blogspot.com is dat de centrale vraag.
Zoals er veel cloud definities zijn, zijn er ook veel security definities. Het artikel rept bijvoorbeeld niet over beschikbaarheid en continuiteit van dienstverlening. Het kan lijken dat cloud (welke versie?) potentieel meer continuiteit biedt dan andere oplossingen, maar welke zekerheid kan worden afgesproken? Als tijd van afname, schaalbaarheid en fysieke lokatie varieren, is zekerheid over continuiteit een mogelijk issue en daadwerkelijk anders dan in de traditionele omgevingen.
Een ander security issue waaraan het artikel voorbij gaat en wezenlijk verschil maakt, heeft te maken met de verschillende wetgevingen in de verschillende landen/continenten. Patriot act, Safe harbour overeenkomsten, Privacywetgeving etc. leggen extra nadruk op een weloverwogen (mede op basis van risicoafweging) keus voor scope, provider en landen/continenten. Tot slot: security heeft ook te maken met gedrag en attitude (zo u wilt: normen en waarden. Juist deze aspecten zijn lastig kwantificeerbaar en moeilijk in SLA’s vast te leggen, zeker als cultuuraspecten een rol gaan spelen. Security experts weten dat dit een boeiend onderdeeel van security is!
Hoewel de beveiligingsmaatregelen binnen cloud computing voor een heel groot deel overeen zullen komen met binnen het eigen bedrijf te treffen beveiligingsmaatregelen, zie ik op het gebied van cloud computing wel degelijk grote verschillen. Het belangrijkste verschil is dat je binnen een interne bedrijfsomgeving veelal niet of nauwelijks rekening hoeft te houden met de scheiding van klantdomeinen. Het feit dat binnen het bedrijf de toegang tot systemen reeds op verbindingsniveau is beperkt tot de eigen medewerkers, beperkt de impact van een mogelijke kwetsbaarheid. Deze kwetsbaarheid zal er immers nooit zomaar toe leiden dat een concurrent die toevallig de zelfde infrastructuur, servers of applicaties gebruikt via een paar foefjes bij jouw klantenbestand kan.
Ik test regelmatig Saas en Paas omgevingen. Dat je bij dergelijke tests op basis van eenvoudige gebruikersrechten toegang krijgt tot vele gigabytes aan data van derden waaronder soms miljoenen persoonsgegevens is hierbij geen uitzondering. Om deze reden adviseer ik klanten altijd eerst hun data zorgvuldig te classificeren en de gevoeligheid van de data mee te nemen in het besluit een hostingdienst bij derden af te nemen. Het zijn immers niet alleen kwetsbaarheden en maatregelen die bij beveiliging een rol spelen, maar ook de bedreigingen en de waarde van de te beschermen data. En volgens mij heb je daar meteen een belangrijk verschil te pakken dat beveiliging in de cloud wel degelijk anders maakt.
Feitelijk is dit verhaal net zo virtueel als de technologie waar het over gaat. Het eindigt namelijk waar het zou moeten beginnen. De cruciale vraag is: wat kan ik als eigenaar van in de cloud opgenomen gegevens eigenlijk controleren? Anders gezegd: bij wie kan een auditor namens mij aankloppen om zijn “controle ding” te doen? Eens met de stelling dat we de onderliggende materie allemaal al wel eens gezien hebben, dat is inderdaad niet zo spannend. Was het al niet maar het kan geen kwaad cloud een beetje te “onthypen”. Wat zeer kan doen in dit verhaal is de suggestie dat het wel mee zal vallen met het security vraagstuk. Voorlopig lijkt dat nog een paar bruggen te ver omdat het cloud concept aanbieders de kans geeft zich achter allerlei constructies te verschuilen. Constructies die de afnemers misschien, in hun haast aan te sluiten bij de hype, of de noodzaak een kostenreductie te realiseren, even over het hoofd zien.
Compliant zijn met wet- en regelgeving betekent dat je aantoonbare beveiliging hebt ingericht. Weten dat de beveiliging goed is geregeld is dus niet voldoende. Heeft de klant met de cloud-provider voldoende afspraken gemaakt over logging, rapportages en kwetsbaarheden- en penetratietesten? Met name de PCI DSS (credit-card transacties en opslag) is hier erg strikt in en verwacht uitgebreide rapportages die aantonen dat de beveiliging goed is ingeregeld. Daarnaast is het voor zowel de Wet Bescherming Persoonsgegevens als voor PCI DSS van belang dat informatie na de houdbaarheidsdatum adekwaat is verwijderd. De cloud-provider zal dus ook hier het bewijs moeten leveren.
Security en cloud is een mooie discussie. Vanuit de security officer worden er vaak zeer terechte vragen gesteld rondom waar staat mijn data, is er ook een iso certificering, audit mogelijkheden, failover scenario’s etc.
Nu wat wij in de praktijk zien gebeuren is dat helaas soms de security officer ook voor een voldongen feit staat, omdat management na een bezoek aan bijvoorbeeld Microsoft of Google en de druk van deze bedrijven zich voor het mooie aanbod van kostenbesparing besluit naar de Cloud te gaan voor een aantal diensten en de security officer dit ook niet tegenhoud.
Vaak worden dan uitgebreide rekenmodellen als bewijs materiaal door deze bedrijven opgevoerd, maar dat wellicht de bandbreedte omhoog moet, de gehele netwerk en security infrastructuur moet worden aangepast zie je niet terug in deze rekenmodellen. Uiteindelijk heeft de security officer dan alsnog de kans en ruimte dit op een gedegen manier in te richten en nog beter dan voorheen, blijft het punt rondom hoe er met de data wordt omgesprongen en welke garanties dan wel SLA’s men hierop kan afsluiten. bij het gebruik van deze Cloud diensten.
Echter zolang nog heel veel bedrijven bijvoorbeeld het wel toestaan om emails met bijlagens door te sturen naar de “Cloud” zoals gmail, hotmail omdat het zo makkelijk is hun email ook op deze manier thuis te lezen of op vakantie en akkoord wordt gegaan met de hierbij geleverde gratis “consumenten security” dient in mijn optiek de discussie rondom Security, hoe dit wordt toegepast, vertaling beleid naar oplossing maar ook de awareness binnen de bedrijven nog steeds veel belangrijker te zijn en ja daar hoort nu zeker ook een visie, strategie en bewuste keuzes nemen bij af te nemen Cloud diensten. Blijft leuk voor ons IT’s en security specialisten!
Bits blijven bits, code blijft code, data blijft data… op welk platform je zo ook loslaat of opslaat..simpel!
Dus geloof niet in domme verkoop-praatjes en blijf je eigen nuchtere verstand gebruiken en blijf lekker met je voeten in de realiteit staan.
Het beveiligen van de Cloud heeft inderdaad dezelfde prioriteit als het beveiligen van het huidige applicatielandschap. Er zit inderdaad een risico dat je zelf niet de volledige controle hebt over je gegevens en applicaties. Maar daarentegen hebben Cloud providers meestal meer en betere security maatregelen genomen dan menig bedrijf zelf.
Bij het controleren van de security van de Cloud is het vooral van belang dat op alle 3 de lagen wordt gecontroleerd. Wanneer er iets mis is op de IaaS laag heeft dat direct effect op de PaaS en SaaS lagen. Ook omdat alle 3 de lagen een andere provider kunnen hebben. Let hierbij om met het testen van de Cloud!
Het werken in “the cloud” kan veilig of onveilig zijn. Net als bij alle ontwikkelingen moet niet geredeneerd worden vanuit de beveiligingsmaatregelen maar vanuit de operationele risico’s. Kijken we naar de bekende onderdelen van informatiebeveiliging dan zullen we zien dat in veel gevallen de beschikbaarheid toe zal nemen, dat er met name twijfel zal zijn bij de exclusiviteit en dat de integriteit geen probleem hoeft te zijn als er duidelijke afspraken worden gemaakt. Kortom: met de juiste risico analyse en beheersingsmaatregelen kan “the cloud” enorme voordelen opleveren maar je bent wel afhankelijk van de volwassenheid van de leverancier.