Mobile security

Inleiding

De combinatie mobile en security blijft een complex fenomeen. Waar voorheen nog enige zekerheid afgedwongen kon worden op basis van de fysieke locatie, is dit in het mobiele tijdperk nauwelijks meer mogelijk. Werknemers zijn flexwerkers geworden, het interne netwerk wordt steeds vaker benaderd via het internet en data wordt in toenemende mate draadloos verzonden en ontvangen.

Ook is er, mede door de snelle ontwikkeling van (ultra)mobiele apparaten zoals tablets, smartphones en smartwatches, een sterke trend merkbaar bij gebruikers om overal en altijd toegang te hebben tot data en functionaliteit. Met de laptop op schoot en de nummergenerator in de hand via VPN inloggen op het bedrijfsnetwerk wordt als omslachtig en tijdrovend beschouwd, zeker wanneer gebruik wordt gemaakt van mobiele devices.

Organisaties staan hierbij voor lastige keuzes: welke data moet op wat voor manier ontsloten kunnen worden op welke toestellen en op wat voor infrastructuur? Daarbij spelen ook de Bring-Your-Own-Device uitdagingen mee, waaronder Mobile Device Management, Device Integrity en voldoende controle op authenticatie.

In dit artikel zullen bovenstaande punten aan de orde komen en diverse mogelijkheden besproken worden. Ter illustratie zal in dit artikel een fictieve oplossing geschetst worden gebaseerd op een opdracht van het ontwikkelen van een mobiele applicatie uit de praktijk van de auteurs, waarbij de combinatie van mobiele devices, zeer vertrouwelijke informatie en het ontbreken van een Mobile Device Management-infrastructuur een grote rol speelde.

Casusbespreking

De casus gaat uit van de volgende doelstelling van de opdrachtgever: ‘Het kunnen raadplegen van zeer vertrouwelijke stuurgegevens via mobiele devices. Doelgroep voor deze informatie is een beperkte groep key users van de betreffende, wereldwijd opererende organisatie.’

De organisatie hanteert een Bring-Your-Own-Device policy; gebruikers kunnen zelf bepalen welk mobiele device ze willen gebruiken. Het mobiele dashboard is het eerste in zijn soort en dient te voldoen aan de hoogste beveiligingsniveaus geldend binnen de organisatie.

De noodzaak voor informatiebeveiliging komt voort uit:

1. concurrentiegevoelige data (stuurinformatie en risico’s).
2. de Risk- en Compliance-organisatie als opdrachtgever binnen deze enterprise. Een onveilige oplossing zou leiden tot gezichtsverlies van deze afdeling en daarmee alle geldende beveiligingsnormen in gevaar brengen.
3. de aard van de onderneming. Klantvertrouwen speelt een zeer belangrijke rol. Bij het lekken van deze informatie leidt dit tot schade aan dit klantvertrouwen.
4. het ontbreken van Mobile Device Management. Daardoor is het niet mogelijk om de devices van afstand te beveiligen. Bij verlies of diefstal van een mobiele device komen de gegevens in handen van derden.

Om de doelstelling te realiseren heeft de opdrachtgever gevraagd een mobiele oplossing te ontwikkelen met sterke focus op databeveiliging, waarmee de data wordt gepresenteerd op een moderne manier zoals men verwacht bij een mobiele applicatie. Deze applicatie zal een aantal randvoorwaarden kennen:

• Er dienen geen directe verbindingen te worden gemaakt met de servers van de klant. De applicatie moet volledig buiten de huidige infrastructuur opgezet worden.
• De client (het mobiele device) kan alleen gegevens inzien, niet wijzigen.
• Gebruikersbeheer dient vanaf een centraal punt ingeregeld te kunnen worden.
• Gebruikers kennen gedifferentieerde autorisatieniveaus. Ze krijgen alleen inzicht in gespecificeerde onderdelen en onderliggende gegevens.

Mobile security-modellen

In de huidige praktijk zijn ruwweg drie implementatievormen van mobile security te onderscheiden:

1. geen specifieke ondersteuning voor mobile devices;
2. ondersteuning voor mobile devices door maatwerk;
3. Mobile Device Management.

1. Geen specifieke ondersteuning voor mobile devices

Onder ‘Geen specifieke ondersteuning voor mobile devices’ wordt verstaan dat er geen processen en technieken zijn ingericht specifiek ter ondersteuning van mobiele devices. Het kan hierbij mogelijk zijn om, gebruikmakend van de interne VPN-functionaliteit, een connectie te leggen met het interne netwerk en via de browser gegevens te raadplegen. Deze methode is in eerste instantie bedoeld voor thuiswerk- of laptopgebruik, en ook hiervoor geoptimaliseerd. Het nadeel van deze implementatie is dat er altijd een extra handeling nodig is om het apparaat te verbinden met het netwerk.

Voor de casus is één van de randvoorwaarden echter dat de oplossing geheel los van de bestaande infrastructuur wordt geïmplementeerd.

2. Ondersteuning voor mobile devices door maatwerk

Bij ‘Ondersteuning voor mobile devices door maatwerk’ worden er zowel in de infrastructuur als aan de kant van de client aanpassingen doorgevoerd specifiek voor het ondersteunen van gegevensuitwisseling tussen de servers en de mobiele devices. Veelal betekent dit dat er per mobiele applicatie authenticatiefunctionaliteit wordt geïmplementeerd, bijvoorbeeld op basis van certificaten. Een nadeel van deze werkwijze is dat voor elke applicatie dit afzonderlijk geïmplementeerd dient te worden. Daarnaast is het ook niet mogelijk om mobiele devices van afstand te beheren. Het is zodoende niet mogelijk het device bij verlies volledig te blokkeren en/of te wissen.

3. Mobile Device Management

Bij Mobile Device Management wordt op het mobiele device een applicatie geïnstalleerd die zich nestelt in het operating system. Als overkoepelende applicatie is deze in staat voor alle applicaties de authenticatie te regelen en alle dataverkeer naar de bedrijfsservers te voorzien van encryptie. Daarnaast biedt Mobile Device Management de mogelijkheid om mobiele devices van afstand te blokkeren en te wissen.

Tabel 1. Mogelijkheden en benodigdheden per mobile security-model.

Van vraag naar functioneel en technisch ontwerp

In het kader van de keuze voor een mobile security-model zijn twee aspecten in het bijzonder van belang: welke mate van beveiliging is er voor de oplossing benodigd, en in hoeverre is de keuze toekomstvast. Er dient daarom een inventarisatie gemaakt te worden in de vorm van een functioneel ontwerp waarbij doordacht wordt welke eisen op het punt van beveiliging en gebruikerservaring aan de oplossing gesteld worden. Hierbij is het van belang de toekomstvisie in acht te nemen; het wijzigen van een reeds geïmplementeerd mobile security-model is een flinke aanpassing.

Wanneer de specificaties in een functioneel ontwerp zijn overeengekomen, kan er een technisch ontwerp worden opgesteld. Voor mobile security ligt de nadruk van dit technisch ontwerp voornamelijk op de gekozen architectuur. Ter afstemming is het noodzakelijk om netwerk- en architectuurspecialisten en security officers te betrekken bij de afstemming, zeker wanneer er gevoelige informatie ontsloten dient te worden.

De randvoorwaarden van de opdrachtgever in de casus bepalen grotendeels de keuze voor een maatwerk mobile security-model; de oplossing dient geheel los van de bestaande infrastructuur te werken en er is geen Mobile Device Management ingeregeld. Gezien de hoge beveiligingseisen aan de data zijn er extra controls nodig om de beveiliging van de overdracht van de data te kunnen waarborgen, iets wat zonder specifieke ondersteuning van mobiele devices niet mogelijk is.

Ontwikkelmethodiek

Grofweg zijn er twee manieren van softwareontwikkeling: gefaseerd (SDM/Waterfall), waarbij er opvolgende perioden zijn van specificeren, ontwikkelen en testen, en timeboxed (agile), waarbij in een vastgestelde tijdseenheid een subset van de totale functionaliteit wordt gespecificeerd, ontwikkeld en getest. Waar de Waterfall-methode erg goed ingezet kan worden in projecten waarbij specificaties kritisch zijn, biedt de agile methode vooral flexibiliteit. Per timebox kan er worden bijgestuurd en opnieuw worden geprioriteerd.

In de casus is er sprake van een duidelijk doel voor de applicatie met vastgestelde randvoorwaarden. De visie voor de uitwerking van de applicatie en presentatie van de data is echter nog niet uitgekristalliseerd; men weet ook niet wat er eigenlijk allemaal mogelijk is. Er wordt daarom gekozen voor een agile werkwijze waarbij de voortgang wekelijks aan de opdrachtgever wordt getoond. Zodoende krijgt de opdrachtgever gaandeweg een beter inzicht in de mogelijkheden en houdt deze de controle op het eindresultaat.

Platformkeuze

Het meest gebruikte platform voor mobiele devices op het moment van schrijven is Android. Het marktaandeel van Apple komt op een tweede plek en Microsoft heeft pasgeleden Blackberry van de derde plaats gestoten ([Frib14]). Applicaties voor een specifiek platform zijn echter niet zonder meer overdraagbaar naar een ander platform; in sommige gevallen dienen ze geheel opnieuw gebouwd te worden in een andere programmeertaal. Er zijn frameworks beschikbaar waarmee, op basis van bijvoorbeeld HTML5, een hybride applicatie te bouwen is, maar deze heeft door de benodigde abstractielaag geen toegang tot specifieke functies zoals encryptie.

Gezien de in de casus geschetste sterke eisen aan databeveiliging dient deze goed geborgd te worden. Deze borging is alleen mogelijk wanneer een applicatie specifiek voor een platform wordt gebouwd. Op het Android-platform is het relatief eenvoudig en soms zelfs ondersteund door de fabrikant om Android zonder Mobile Device Management open te breken (op Android genaamd ‘rooten’). Apple is daarentegen faliekant tegen het iOS-equivalent van ‘rooten’ (genaamd ‘jailbreaken’) en repareert actief kwetsbaarheden die worden misbruikt voor het ‘jailbreaken’. Omdat beveiliging binnen deze applicatie van zeer groot belang is, is gekozen voor het iOS-platform van Apple.

Databeveiliging

Om de beveiliging van de data te garanderen dienen er controls ingebouwd te worden in de applicatie. Bij elk systeem dat verbinding legt met een ander systeem kan het opzetten van een verbinding in drie stappen worden onderverdeeld: identificatie, authenticatie en autorisatie. Bij de identificatie maakt de client zich bekend bij de server. Vervolgens authenticeert de server zich eerst aan de client, meestal door middel van een PKI-certificaat. Wanneer de client de authenticiteit van de server heeft gevalideerd, wordt er een beveiligde verbinding opgezet. De server biedt de client vervolgens over deze beveiligde verbinding de mogelijkheid om zich te authenticeren, vaak door middel van credentials zoals gebruikersnaam en wachtwoord. Bij succesvolle authenticatie wordt door de server het autorisatieniveau opgehaald waarmee bepaald wordt welke data door de client mag worden ingezien en/of worden gewijzigd.

Een mobiele device kent unieke identificatiecodes. Deze kunnen hardwarematig zijn, of gegenereerd op basis van de hardware-identificatiecode en de unieke code van de softwareleverancier. Op basis van deze code kan een gebruiker gekoppeld worden aan een mobiele device, waarna hij wordt toegestaan zich te authenticeren. Na succesvolle authenticatie krijgt de gebruiker uiteindelijk de data te zien waarvoor hij geautoriseerd is.

Uitwerking

Met ‘Ondersteuning voor mobile devices door maatwerk’ als uitgangspunt is er uiteindelijk een client-serveroplossing ingericht. De clientapplicatie is door middel van een beveiligde SSL-verbinding verbonden met de serverapplicatie, waarbij het PKI-certificaat van de server wordt gevalideerd tegen de verwachte waarde die in de clientapplicatie is ingeprogrammeerd (het zogenaamde ‘certificaat-pinning’). De serverapplicatie is gekoppeld aan de LDAP-(gebruikers)database van de organisatie en op de server is er een apart gebruikers- en autorisatiebeheerpaneel ingericht. Bij de eerste keer aanmelden op het mobiele device moet de gebruiker zich authenticeren gebruikmakend van zijn corporategegevens, en kan hij een PIN opgeven. Tezamen met de unieke identificatiecode van het mobiele device worden deze gegevens getoetst en opgeslagen op de server. De benodigde data kan vervolgens worden opgevraagd door middel van de unieke identificatiecode van het mobiele device gekoppeld met de door de gebruiker opgegeven PIN. Daarnaast bevat de clientapplicatie een scala aan controles om de integriteit van het mobiele device en de applicatie zelf te valideren. Dit om het gebruik van de applicatie op ‘jailbroken’ devices tegen te gaan en malafide aanpassingen van de applicatie te voorkomen.

Bovenstaande oplossing voorziet in de eis dat geen data wordt opgeslagen op het mobiele device zelf. Er vindt altijd een dubbele authenticatie plaats door de koppeling met de LDAP, waardoor het snel mogelijk is om een mobiele device toegang tot de data te ontzeggen.

Figuur 1. De gerealiseerde app.

Lessons Learned

Gedurende de uitvoering van de praktijkcasus is er sterk gestuurd op kennisuitwisseling en riskanalyse. Een belangrijke succesfactor hierbij was het identificeren en betrekken van alle stakeholders vanaf het begin bij het project. Het betrekken van een securityexpert is hierbij van zeer grote waarde aangezien deze vanuit het perspectief van een hacker waardevolle toevoeging kan bieden aan het identificeren en mitigeren van de risico’s.

Uitgangspunt voor een dergelijke applicatie is de stelling ‘Mobiele devices zijn in principe altijd onveilig.’ Daaraan gerelateerd mag gevoelige data (waaronder inloggegevens) nooit op een mobiele device opgeslagen worden. De kans dat deze gegevens kunnen worden achterhaald op een mobiele device is door ‘rooten’ / ‘jailbreaken’ vele malen groter dan wanneer ze op een goed beveiligde server zijn opgeslagen.

Bij de ontwikkeling van een mobiele applicatie met specifieke focus op databeveiliging is het verstandig om te richten op een specifiek platform zodat optimaal gebruik kan worden gemaakt van de platformspecifieke beveiligingsmethoden. Door compilatie van de broncode wordt deze bovendien obfuscated (onleesbaar gemaakt). Een kwaadwillend persoon kan daardoor niet meer direct de broncode lezen, met als gevolg dat eventuele kwetsbaarheden ook lastiger te ontdekken zijn.

Ten slotte: men moet zich ervan bewust zijn dat het onmogelijk is om gevoelige data te ontsluiten via mobiele devices zonder de beveiliging in gevaar te brengen. Bij beschikbaarstelling wordt beveiliging altijd in gevaar gebracht. De in dit artikel beschreven maatregelen en controls kunnen slechts de kans op dit risico minimaliseren als aanvulling op reeds bestaande procedures.