App-explosie bedreiging voor mobiele omgeving

Share this post:

Tijd om afscheid te nemen van defensief beveiligingsbeleid

De veiligheid van mobiele apparaten wordt steeds vaker ter discussie gesteld. Niet zelden berichten media over de ontdekking van malware op mobiele apparaten die het ontvreemden van gevoelige informatie zoals bankgegevens mogelijk maakt. Het European Network and Information Security Agency (ENISA) waarschuwt zelfs dat smart devices het favoriete doelwit voor hackers vormen. Met name de beveiliging van apps schiet tekort doordat ontwikkelaars de benodigde kennis missen.

Beveiliging apps op de proef gesteld door exploits
Dezelfde haast waarmee de eerste websites in de jaren ’90 werden gelanceerd is momenteel zichtbaar in het aantal aanvragen waarmee app-ontwikkelaars worden overspoeld. Een ontwikkeling die niet uit de lucht komt vallen: in 2016 zal het aantal smartphones en tablets de totale wereldpopulatie overstijgen. Bovendien blijkt uit eerder onderzoek dat consumenten van smart devices maar liefst 95% van hun tijd aan apps besteden. De enorme vlucht van de app gaat echter gepaard met risico’s op het gebied van beveiliging. Zeker sinds vertrouwelijke toepassingen zoals internetbankieren hun weg naar de smartphone vinden, wordt de beveiliging van apps op de proef gesteld door exploits die vaak pas achteraf herkend en hersteld kunnen worden.

Verouderd beveiligingsbeleid
Hoewel de discussie anders doet vermoeden, zijn smartphones vanuit beveiligingsperspectief erg goed ontworpen. Dankzij het sandboxing model is het besturingssysteem minder vatbaar voor virussen, mits gevrijwaard van bijvoorbeeld jailbreaks. Marc van Zadelhoff, VP Strategy bij IBM Security Systems, verwacht zelfs dat mobiele apparaten eind 2014 veiliger zullen zijn dan laptops dankzij technologie die zich toelegt op het veiligstellen van de data in applicaties. Er moet nog wel een lange weg bewandeld worden. De huidige benadering van beveiligen is namelijk te defensief: nu worden er maatregelen genomen tegen elk risico dat zich voordoet. Dat is onhoudbaar nu zowel het volume als de intelligentie van mobiele aanvallen zich in razend tempo ontwikkelen. Controlemechanismes zijn nodig om zowel het mobiele apparaat, het netwerk als het applicatieplatform te beveiligen.

Kwaadaardige codes toveren onschuldige app om tot groot beveiligingsrisico
De achilleshiel van smartphones is de app. Deze is het doelwit bij uitstek om toegang te krijgen tot een smartphone. Om mobiele apps te voorzien van native functies, denk bijvoorbeeld aan het activeren van de camera op je smartphone, zijn API’s (Application Programming Interfaces) geïntroduceerd. Veel API’s zijn nog in ontwikkeling en bevatten kwetsbaarheden die zich prima lenen voor misbruik. App-ontwikkelaars beschikken vaak niet over voldoende beveiligingskennis om dergelijke lekken te voorzien tijdens het coderen. Dit in tegenstelling tot traditionele systeemontwikkelaars.

Kwaadaardige code of data injecties kunnen een op het oog onschuldige app omtoveren tot een groot beveiligingsrisico. Een simpele QR-code kan soms al genoeg zijn om je smartphone blijvend te beschadigen indien de toegangsrechten van de QR-app niet voldoende afgebakend zijn. Ook de klassieke man-in-the middle aanval is een bekend verschijnsel, waar communicatie tussen de app en de backend API’s onderschept wordt om vertrouwelijke informatie te stelen, of zelfs de controle over de smartphone te bemachtigen. Momenteel wordt geprobeerd de risico’s te beperken door één distributiekanaal te hanteren.

Kwaadaardige apps kunnen zo van de onschuldige gescheiden worden. Heikel punt is dat de distributiesnelheid van updates beperkt is. Intermediairs zoals een applicatieplatform moeten updates eerst verifiëren, wat de responsetijd verhoogt en apps langer dan nodig blootstelt aan risico’s.

Start bij het codeerproces
Goede analysetools wijzen ontwikkelaars al tijdens het codeerproces op verhoogde risico’s en hebben daarmee tegelijkertijd een onderwijzende en risicobeperkende rol. Dit scheelt organisaties veel ontwikkelkosten voor updates die later plaatsvinden in de app-lifecycle. Minstens zo belangrijk is dat deze tools een schat aan kennis opbouwen die toegepast kan worden op toekomstige API’s.

Een volgende stap is het inbouwen van controlemechanismes in het applicatieplatform om te valideren of apps tussentijds gewijzigd of geïnfecteerd zijn. Een dergelijk platform moet een proces bevatten dat ontwikkelaars toestaat om direct apps te blokkeren en updates te distribueren wanneer zij dit nodig achten. Ook dient dit platform tools te leveren die beveiligingsmaatregelen vlekkeloos integreren tijdens het ontwikkelproces, zoals bijvoorbeeld bij dataencryptie.

Een goede beveiliging vereist daarnaast een gelaagde, contextbewuste aanpak die in staat is om gebruikers en interacties te herkennen en te autoriseren. Het moet standaard beleid worden om toegangsrechten tot een app te bepalen aan de hand van een nauwkeurige risicobeoordeling van de context. Denk hierbij aan variabelen zoals de locatie, de staat van de smartphone, andere apps, het gebruikte netwerk en zelfs het tijdstip. Wanneer dit beveiligingselement opgenomen wordt in een bovenliggend applicatieplatform in plaats van de app zelf, kunnen ze simpeler en gebruiksvriendelijker ontwikkeld worden.

Daarnaast bieden deze controlemechanismes een duurzaam instrument om cybercriminaliteit tegen te gaan. Een deel van de app-beveiliging wordt immers overgeheveld, waardoor het risico dat ontwikkelaars kwetsbare coderegels inbouwen sterk afneemt. Ontwikkelaars worden niet meer gedwongen om het wiel telkens opnieuw uit te vinden, zodat het volume en de intelligentie van mobiele aanvallen beheersbaar kan worden gehouden.

Bovenstaande stappen vormen de basis om het huidige defensieve beveiligingsbeleid te vervangen door een getrapte benadering die over de hele linie beveiliging biedt. Organisaties en consumenten worden in mindere mate afhankelijk van de kennis en kunde van een ontwikkelaar, die zijn aandacht weer kan richten op het ontwerp van de app zelf.

Door Peter Volckaert, IT Security Architect bij IBM – peter.volckaert@be.ibm.com.

 http://ow.ly/mPkzZ

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:””;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:”Times New Roman”;
mso-fareast-font-family:”Times New Roman”;
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}