Beheer

Security
Heartbleed logo1

Heartbleed zorgt voor businesscase SDN

© Heartbleed
19 september 2014

 

Kwetsbaarheden met de omvang van Heartbleed komen niet vaak voor. De bug heeft zelfs zijn eigen website en logo gekregen, en wordt zowel binnen als buiten de IT-wereld besproken. Bedrijven zijn bezorgd, eindgebruikers ook. Bijna iedereen heeft er mogelijk mee te maken (gehad), waardoor het een van de grootste beveiligingsproblemen is van de afgelopen jaren zowel qua impact als omvang.

Uiteindelijk komt het allemaal goed natuurlijk. De ophef wordt minder en we vinden manieren om ons te beschermen tegen dit soort bugs. Patches worden snel ontwikkeld en uitgedeeld, maar tot die tijd loop je nog wel steeds risico. Dat leidt tot een serieuze vraag: hoe kunnen bedrijven zo’n plotselinge hartbloeding stelpen, zodat ze tijd krijgen om naar de operatiekamer te gaan om het probleem definitief te verhelpen?

Een van de opties is om het hele systeem op zwart te zetten. Trek de stekker eruit om de bedreiging te elimineren. Maar in werkelijkheid is dit natuurlijk niet echt een optie. Bedrijven moeten met de kwetsbaarheid omgaan terwijl ze een langetermijnoplossing regelen.

 

Vergeten optie

Software Defined Networking biedt in essentie een scheiding van de controle op de data en het transport van die data door het netwerk. De Open Networking Foundation promoot al geruime tijd de inzet van SDN, en in zijn eerste gepubliceerde documenten over de voordelen ervan valt op dat het onder andere ging over de ondersteuning van het ‘experimental protocol’. Dit werd neergezet als een mogelijkheid voor organisaties om nieuwe en experimentele protocollen in een netwerk te ondersteunen zonder dat je hoeft te wachten op leveranciers die eerst koppelingen en andere implementaties moeten ontwikkelen. Het zorgt dus voor een mate van programmeerbaarheid in een netwerk.

Dit concept hebben de meeste bedrijven tot op heden genegeerd. Maar de opkomst van Heartbleed en de vraag hoe je met dit soort kwetsbaarheden omgaat, is reden genoeg om de programmeerbaarheid in een netwerk te heroverwegen. Vandaag de dag wordt dit namelijk vooral gebruikt in het controlepad om automation en orchestratie mogelijk te maken. Programmeerbaarheid is echter niet alleen geschikt als controlemiddel om datatransport per applicatie te optimaliseren, maar ook om het daadwerkelijke transport van data door het netwerk te manipuleren. Je kunt daardoor veel sneller inspelen op actuele gebeurtenissen, of ze nu kwaadwillend zijn of niet.

 

Misbruik

Heartbleed maakt misbruik van een lek in de versleutelingstechnologie OpenSSL. Meer specifiek gaat het om een programmeerfout in het TLS/DTLS-transportprotocol. Hierdoor is het mogelijk om het gebruikte systeemgeheugen van een kwetsbare OpenSSL-versie uit te lezen waardoor gebruikersnamen, wachtwoorden en sleutels van certificaten vrij toegankelijk zijn.

Het probleem zit hem in het misbruik van het protocol. Een SDN-architectuur zou in staat moeten zijn om programmeerbaarheid ook in het transport van data te kunnen toepassen. Hierdoor kan de originele afhandeling van het protocol, waar de kwetsbaarheid dus in zit, worden aangepast met een alternatieve afhandeling waarbij een kwaadwillend request kan worden herkend en geweerd, voordat het überhaupt naar de kwetsbare server gaat. Maar dat vereist een architectuur die nog niet bestaat. Momenteel kun je met SDN-architecturen wel applicaties ontwikkelen die deze functionaliteit bieden, maar zo’n oplossing is niet direct voorhanden en vereist een ontwikkeling die net zoveel tijd kost als het leveren van een patch. Je blijft dan dus achter de feiten aanlopen, met alle gevolgen van dien voor de bedrijfsvoering.

Het concept van programmeerbaarheid van datatransport is dus interessant. Wanneer de weg die data bewandelen door programmeerbaarheid gemanipuleerd kan worden, krijgen organisaties de kans direct maatregelen te nemen tegen kwalijke requests en risico’s op verder misbruik te voorkomen. En het geeft bedrijven de tijd om een permanente oplossing te vinden. Dit is nu al te doen met application delivery controllers, maar je mag dat ook van een SDN-architectuur verwachten. Bedrijven die hierin investeren, willen immers hun hele IT-infrastructuur, inclusief diensten én beveiliging, op een hoger plan brengen.

Echter, SDN is nog aan het groeien, en de voordelen van programmeerbare datapad-elementen als onderdeel van de grotere architectuur zijn ondergesneeuwd door de operationele voordelen, zoals automation en orchestratie. Maar Heartbleed herinnert ons eraan dat we er nog niet zijn. We hebben de mogelijkheid om netwerkgedrag middels programmeerbaarheid aan te passen aan protocollen. Laten we die niet over het hoofd zien.

Een architectuur die nog niet bestaat

Bij SDN wordt OpenFlow of Opflex in het controlpad gebruikt als communicatie tussen switch en controller. Het concept spreekt van het gebruik van OpenFlow in het transport van de data oftewel het datapad, hierdoor wordt het mogelijk om gebruik te maken van ondersteuning die OpenFlow biedt voor experimentele protocollen. Hierdoor voeg je programmeerbaarheid toe aan het datapad waardoor in het geval van Heartbleed de kwetsbaarheid uit het protocol kan worden gehaald. De ondersteuning van experimentele protocollen als concept is totaal genegeerd door de industrie en wordt alleen gebruikt in R&D-labs en op universiteiten. Dit is een traditioneel beeld dat wellicht niet snel te doorbreken is. Ondanks het feit dat met de ondersteuning van experimentele protocollen een weg vrij is gemaakt om veel eenvoudiger applicaties te ondersteunen met een protocol dat volledig is afgestemd op de toepassing. Wellicht is dit ook een vrucht van de vergaande standaardisatie die we de laatste tien jaar hebben doorgemaakt, met als sprekende voorbeelden TCP/IP en ethernet (en daardoor de inperking van de wildgroei van en ontwikkeling aan leverancierspecifieke protocollen).

Stappenplan

Er is op dit moment nog geen concreet stappenplan waarmee de IT-beslisser aan de slag kan. De beschreven aanpak is een concept dat gebruik maakt van het fundament dat SDN heeft neergelegd, maar wat wellicht een volgende stap in de evolutie van SDN kan zijn. Toch zijn er wel degelijk voorbereidingen te treffen of zelfs al eerste stappen te nemen. Wanneer we naar de essentie van SDN kijken en wat het brengt, dan is dat programmeerbaarheid, centralisatie van functies en beheer, een hoge mate van flexibiliteit in het netwerk dat beter kan worden afgestemd op de toepassingen, en het gebruik van open standaarden. Dit zijn allemaal eigenschappen die van belang zijn en vandaag de dag al te vinden zijn in een application delivery controller. Dus zolang het concept van programmeerbaarheid in het datapad in SDN niet is uitgewerkt, kan deze functie door een ADC worden vervuld.

Application delivery controller

Een application delivery controller (ADC) functioneert op laag 4-7, terwijl SDN zich richt op de lagen 2 en 3 van het OSI-model, waar het netwerk is gedefinieerd. Een ADC is dus in staat om te participeren in een SDN en in een traditionele infrastructuur en kan functioneren als gateway met application delivery als extra toevoeging. Een volwaardige ADC biedt naast een full-proxy architectuur, hoge performance en SSL-offloading, programmeerbaarheid van management, data en controlepaden. Deze ingrediënten zorgen ervoor dat je een sterke basis hebt voor totale controle over hoe applicaties worden aangesproken door gebruikers en bieden de mogelijkheid om een bug als Heartbleed in een aantal uren te patchen in plaats van te wachten totdat de softwareproducent een patch levert.

Voorbeeld van het patchen met iRules:

Discussie over voordelen

Hoewel er wel voordelen van SDN zijn te noemen, is het lastig een algemeen beeld hiervan te geven, omdat het per situatie kan verschillen. De discussie die momenteel gaande is op het beveiligingsvlak is namelijk of de komst van SDN de infrastructuur nu veiliger of onveiliger maakt. Critici menen dat het centraliseren van de controle een groot risico met zich meebrengt omdat een geslaagde hack direct de totale controle van het netwerk oplevert, terwijl de voorstanders juist menen dat zonder centralisatie geen goed overzicht valt te verwerven en dit mede debet is aan inconsistente beveiliging door het ontbreken van de context. Deze discussie betreft echter het controlepad waar de intelligentie van SDN staat opgesteld in de vorm van een controller en niet het datapad waar dit artikel zich op concentreert.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!