Cloud Computing Risico’s en risicoreductie
Inleiding
In dit overzicht staan de verschillende aandachtspunten rond Cloud Computing gegroepeerd rond het thema risico’s en risicoreductie. Doel van het overzicht is helderheid te verschaffen over de punten waar een organisatie aan moet denken als die structureel gebruik gaat maken van Cloud Computing.
Bronnen
Bronnen voor dit overzicht zijn onder meer informatie uit documentatie van ENISA, Berkely University en de Cloud Security Alliance.
Cloud Computing
In dit overzicht gebruik ik de volgende definitie van Cloud Computing.
De Cloud scheidt applicatie en informatiebronnen van de onderliggende structuur en de mechanismen om ze te leveren. Deze definitie beperkt zich hier tot Software as a Service (SaaS). Andere XaaS Cloud Computing vormen zijn hiermee uitgesloten van de beschouwingen in dit overzicht.
De overgang naar Cloud Computing gaat gepaard met emotie. Een organisatie geeft zijn data ‘weg’ aan een externe partij en wat overblijft is een gevoel van verlies van controle. Control wil zeggen dat er deugdelijke controles aanwezig zijn en dat hun effectiviteit bewezen is. De rationele component bij een overgang naar Cloud Computing regelt dat er contracten zijn met mantelovereenkomsten en SLA’s, dat de beveiliging ingebouwd is en dat verantwoordelijkheden worden overgedragen.
Business belangen
Cloud Computing komt niet uit de lucht vallen en het is geen IT speeltje maar de business belangen spelen een grote rol. Toch moet goed worden beoordeeld in hoeverre de business belangen niet worden belemmerd door de overgang naar de Cloud. Dat kan door de verschillende bedrijfsprocessen en de daarmee gepaard gaande informatie te beoordelen op geschiktheid voor Cloud Computing. Ruwweg zijn er drie vormen mogelijk: geschikt, na aanpassing geschikt en ongeschikt. Verder zijn er verschillende vormen van Cloud Computing mogelijk tussen de beide uitersten Private Cloud en Public Cloud, denk hierbij aan Private Cloud (intern of on site), Private Cloud (extern, inclusief dedicated of gedeelde infrastructuur), Hybride omgevingen, Community en Public Cloud. De organisatie moet eerst per bedrijfsproces of -applicatie bepalen of dit geschikt is voor de Cloud. Daarna volgt de vaststelling welk type Cloud het meest geschikt is.
Voor het bepalen in hoeverre een bedrijfsproces of –applicatie geschikt is voor de Cloud, is de beantwoording van de volgende vragen essentieel.
Opbouw van een autorisatiematrix
Een bedrijf dat groot genoeg is om controle van de boeken te krijgen, met meerdere werknemers in dienst, heeft een autorisatiematrix nodig. Dit kan al een heel eenvoudig lijstje zijn:
| Inboeken | Uitboeken | Factureren | Accorderen | Betalen | |
| Jan | V | X | X | X | V |
| Piet | X | V | X | X | X |
| Kees | X | X | V | X | X |
| Clara | X | X | X | V | X |
Het doel van een autorisatiematrix moet zijn inzicht te krijgen (en te houden) in de rollen die een medewerker heeft. Dit doe je bijvoorbeeld om mogelijke frauduleuze handelingen te voorkomen. Iemand zowel de rechten geven op het accorderen als het betalen van facturen vertoont grote gelijkenis met het verhaal van de vastgebonden kat op het spek.
In grotere organisaties geldt dat het moeilijk is om overzicht te houden over het aantal en de soort uitgegeven rechten. Door rechten aan rollen te koppelen knip je het probleem al in kleine stukken. Medewerkers kunnen een of meer rollen vervullen en hebben daardoor automatisch rechten. In de autorisatiematrix zorg je ervoor dat rollen geen conflicterende rechten hebben en dat rollen zelf niet met elkaar in conflict mogen zijn. Je houdt de autorisatiematrix alleen in stand als je er een goed beheerproces omheen bouwt.
Medewerkers veranderen van functie binnen een bedrijf, maar het komt zelden voor dat de rechten (autorisaties) van deze medewerkers worden aangepast. Een andere veel voorkomende bron van vervuiling is dat een nieuwe medewerker een kopie van het profiel van zijn voorganger krijgt. Zeker als deze voorganger een rijke historie binnen het bedrijf heeft, zal de nieuwe medewerker veel extra rechten krijgen die hij niet nodig heeft voor het uitvoeren van zijn functie.
De meest zekere methode om te voorkomen dat een medewerker teveel rechten heeft is om zijn rechten af te nemen als hij een nieuwe functie gaat vervullen. Daarna kunnen hem de rechten worden toegekend die bij zijn nieuwe functie horen.
Als je dit verder uitwerkt ben je al aardig op weg in de richting van een RBAC (Role Based Access Control) traject.
Onzinnige IB maatregelen – akkoord voor inloggen
In de serie onzinnige informatiebeveiligingsmaatregelen, vandaag het akkoord voor inloggen.
Enkele bedrijven hebben deze maatregel ingevoerd, waarbij je als gebruiker voor of na het inloggen akkoord moet gaan met de gedragscode op het netwerk. Dit is de digitale variant van het bordje “Verboden toegang, art. 461 W.v.Sr.”. Dat is tevens de zwakte van het systeem. Als je als organisatie hieraan begint, dan dien je er wel voor te zorgen dat je op alle digitale toegangen een dergelijk bordje zet. Anders kan iemand die zich toegang heeft verschaft via een onbekend kanaal stellen dat hij niet wist dat het niet mocht, er hing immers geen bordje.
Door aan gebruikerszijde deze melding te plaatsen laat je de gebruikers een of twee extra handelingen verrichten voordat zij op het netwerk zijn. Dit wordt al snel een routine, zonder dat de tekst wordt gelezen of begrepen. Dat komt het beveiligingsbewustzijn niet ten goede en is een verkeerde manier van toepassen van het informatiebeveiligingsbeleid.
Verder kun je je afvragen wanneer je de melding moet tonen, voor of na het inloggen. Voor het inloggen zou betekenen dat een gebruiker nog kan weigeren. Maar hij heeft een overeenkomst of opdracht, waarin al de zaken met betrekking tot beveiliging zijn geregeld. Niet accorderen is geen optie en de maatregel voegt niets toe. Na het inloggen tonen heeft evenmin een toegevoegde waarde, men is immers – logisch gezien – al binnen. Dat is het hetzelfde als een portier binnenzetten om ongewenste gasten buiten te houden.
Organisaties die iets met een akkoord verklaring willen doen kunnen dat beter regelen met algemene voorwaarden voor het gebruik van IT middelen. Door die jaarlijks te ondertekenen, bijvoorbeeld tijdens integriteitssessies of door het bij de beoordelingsgesprekken op de agenda te zetten, wordt eveneens voldaan aan het kenbaarheidsprincipe. “Ik wist het niet” is daarmee geneutraliseerd.
Gebruikers die zich regelmatig actief akkoord verklaren zijn zich daar veel meer van bewust dan degenen die dagelijks een vakje aanvinken en op OK klikken.
Instant messaging in een bedrijfsomgeving
Veel grotere bedrijven, waaronder (delen van) de rijksoverheid maken gebruik van instant messaging (IM). Dat kan voor intern gebruik zijn, of om contacten te onderhouden met de buitenwereld. Er zijn verschillende aanbieders van enterprise oplossingen voor IM. Zij onderscheiden zich bijvoorbeeld door IM protocollen van andere leveranciers te ondersteunen, virusprotectie of beheer van accounts.
Logging
Een functionaliteit die veel van deze producten hebben is het loggen (registreren) van verbindingen. Dan kan zowel centraal (op de server) als lokaal (bij de client op de desktop) zijn ingesteld. Iemand die deze blog volgt voelt hem al aankomen, hier zit een privacy luchtje aan.
Van e-mail weten we dat er registratie plaatsvindt bij het verzenden en ontvangen van e-mailberichten. De mails zelf worden vastgelegd in de mailbox. Dat moet ook wel, anders heb je er niets aan. E-mail kan gebruikt worden als bewijsgevend materiaal. Voor IM, dat niet echt is ingeburgerd in het bedrijfsleven, zou je soortgelijke regels verwachten. Toch komen de meeste clients met een voorinstelling waarbij de logging uitstaat.
Accounts
Een bedrijf zal eveneens zelf het beheer van de IM accounts willen uitvoeren, om de professionele uitstraling te kunnen handhaven. Dit is natuurlijk vooral van belang bij externe contacten. Iemand met de alias ‘lekkerding88@hotmail.com’ komt net zo serieus over als ‘leethaxor@yahoo.com’. Gesteld dat een accountmanager een dergelijke IM account gebruikt bij zijn zakelijke contacten, dan zal dat de professionele uitstraling van de organisatie nadelig beïnvloeden.
Het controleren van de bedrijfspolicy met betrekking tot de naamgeving is een ding. Een organisatie zal het eveneens niet waarderen als een ex-medewerker de accountnaam ‘janssen-bedrijfsnaam@hotmail.com’ blijft hanteren na zijn vertrek. Centraal beheer van IM accounts is een belangrijk punt. Bij het selecteren van de enterprise oplossing voor IM moet beheer van accounts deel uitmaken van de oplossing.
Beleid
IM berichten zijn vaak kort en informele krabbels, waarbij vastlegging – vanuit gebruikerstandpunt bezien – niet nodig of gewenst is. Voor bedrijven kan dat anders zijn, zeker als er contacten met externe partijen worden onderhouden met behulp van IM. Centrale logging van dat IM verkeer kan dan zeker gewenst zijn, bijvoorbeeld voor bewijsvoering. Meestal gaat hierbij de voorkeur naar het vastleggen van de gegevens bij de client software. Dat levert trouwens wel problemen op bij ontslag van een medewerker.
Voor mailboxen zijn vaak protocollen ingeregeld waarbij eisen zijn geformuleerd over de omstandigheden waaronder een mailbox wordt geopend, om de privacy van de medewerker te beschermen. Bij IM moet dit eveneens geregeld worden, de werkgever kan hier een belang hebben, zoals het nakomen van afspraken met derde partijen die door betrokken medewerker zijn gemaakt. Een methode om dit te borgen is het opstellen van voorwaarden voor het gebruik van IM. Daaronder kan het vastleggen van IM conversaties horen, net als richtlijnen voor het gebruik van de account.
Als dit proces goed is ingeregeld, zal het privacy luchtje niet gaan stinken.
Draagplicht van toegangspassen
Regelmatig duikt de discussie op over de draagplicht van toegangspassen in een bedrijf of organisatie. Uitgangspunt hierbij is wel dat een organisatie deze passen al heeft en dat ze zijn voorzien van een pasfoto. Het voordeel van dergelijke passen is dat ze – mits regelmatig onderhouden – een goed intern identificatiemiddel vormen en vaak van meerdere functies zijn voorzien. De betaalfunctie (chipknip) is daar een voorbeeld van. Nadelen zijn er ook. Deze passen zijn verhoudingsgewijs duur en hebben een infrastructuur nodig om goed te kunnen werken. Daarbij moet er eveneens beheer worden uitgevoerd wat het nodige kost.
Een bedrijf dat besluit de draagplicht in te voeren voor toegangspassen wordt direct geconfronteerd met allerlei weerstanden. Veel mensen vinden of voelen dat zij in hun persoonlijke levenssfeer worden geraakt. Dat is een verzwarende factor bij de controle op naleving van het beleid.
De kans dat een dergelijke maatregel gaat werken is nog het grootst in een strak geleide hiërarchische organisatie waar men overwegend in bedrijfskleding loopt en werkt. Zelfs dan is zichtbaar commitment van het management nodig om van deze maatregel een succes te maken. De herkenbaarheid van bezoekers zal alleen goed werken als de draagplicht strikt gehandhaafd wordt. Natuurlijk moet bij het invoeren van deze maatregel nadrukkelijk gekeken worden naar de beoogde veiligheidsopbrengst. Het management en de afdeling informatiebeveiliging dienen goed in beeld te hebben wat er met deze zware maatregel beschermd moet worden.
Mocht een volledige draagplicht niet haalbaar zijn, dan zijn er enkele compenserende maatregelen mogelijk waardoor het vereiste beveiligingsniveau alsnog benaderd kan worden. Hierbij kun je denken aan het steeds begeleiden van bezoekers en het afschermen van ruimtes met (bijvoorbeeld) vertrouwelijke informatie. Deze ruimtes zijn dan niet te betreden met een bezoekerspas. Verder moet in alle ruimtes met vertrouwelijke informatie een cleandesk policy van kracht zijn, waardoor informatielekkage wordt bemoeilijkt. Om meelifters (piggy-backing) bij het betreden van een vertrouwelijke zone tegen te gaan kun je denken aan de invoering van mantraps of eenpersoons sluizen.
Voorkomen van misbruik van passen die toegang geven tot de vertrouwelijke zones is een ander fenomeen. Je kunt dit beheersen door aanvullende eisen te stellen aan de bezoeker. Bijvoorbeeld het vragen van een pincode of gebruikmaken van biometrische identificatie. Alweer, de kosten van de beveiliging moeten in balans zijn met de waarde van hetgeen beschermd wordt.
De sterkste maatregel die een organisatie in kan zetten wordt gevormd door het eigen personeel. Als iedereen het belang begrijpt van cleandesk, het begeleiden van bezoekers en onbekenden durft aan te spreken, dan is de kans op ongewenst bezoek het kleinst.
Daar kan geen draagplicht tegenop.
Onzinnige IB maatregelen – email disclaimers
In het kader van, omdat het kan, het eerste deel van mijn nieuwe en onregelmatig te verschijnen serie columns waarin ik onzinnige (lees: nutteloze) informatiebeveiligingsmaatregelen van dichtbij bekijk. Vandaag: de emaildisclaimer.
Je ziet ze (nog) steeds, de disclaimer onder emailberichten. Daarin tref je allerhande opmerkingen aan die de kracht van de boodschap proberen teniet te doen. Of ze stellen dat je – als je het bericht ten onrechte hebt ontvangen – de afzender moet informeren en verder niets met de gegevens mag doen, behalve het mailtje verwijderen. Ik zal ze beiden behandelen.
De disclaimer die alle gedane uitspraken in het bovenstaande bericht ongeldig maakt is volgens mij verouderd. Inmiddels gaat het grootste deel van de afspraken per email, waardoor deze variant van de disclaimer geen bestaansrecht meer heeft. Daarnaast is het een belediging van de ontvanger. Immers, deze neemt de gelegenheid en tijd om je emailbericht te lezen, terwijl jij onderaan het mailtje de (ongetwijfeld juridisch correcte) mededeling plaatst dat hij in feite zijn tijd zat te verdoen. Beter is het dan om de disclaimer bovenaan het bericht te zetten: trek je niets aan van hetgeen hieronder staat, je kunt er immers toch geen rechten aan ontlenen. Een ontvanger kan het bericht dan direct weggooien en verspilt zo niet meer tijd dan nodig is.
De andere variant van de disclaimer gaat er kennelijk van uit dat de afzender erg veel fouten maakt bij het versturen van emails, anders had hij hiervoor nooit een mooie standaardtekst opgesteld. Toch is het een raar verhaal. Je ontvangt een bericht, je opent het en leest het. Gaandeweg trek je de conclusie dat het niet voor je bestemd is. Onderaan lees je dat je het bericht niet had mogen lezen en dat je er niets mee mag doen. Maar je moet wel de afzender informeren. Van deze disclaimer kun je stellen dat hij overbodig is. En: “What has been seen cannot be unseen”. Een organisatie die zijn processen op orde heeft verstuurt geen structureel verkeerd geadresseerde emailberichten. Bedrijven die deze disclaimers nodig denken te hebben kunnen beter hun energie in andere zaken steken.
Mijn conclusie: disclaimers onder (of boven) emails zijn overbodig. Vaak worden ze pas op de mailserver automatisch aan berichten toegevoegd en ziet de opsteller van het bericht ze niet eens. Daarmee verdwijnt zelfs het laatste beetje nut van deze bits en bytes.
Informatiebeveiliging 