Ontwikkelaars en hun opdrachtgevers denken vaak dat applicaties goed beveiligd zijn zodra encryptie is toegevoegd. Maar wanneer die versleuteling van informatie niet goed is ingericht of slechts gedeeltelijk wordt toegepast, biedt encryptie slechts schijnveiligheid. In dat opzicht kun je het vergelijken met een traditionele virusscanner die ook geen enkele garantie biedt tegen indringers.
Over deze blogger
Martijn Sprengers MSc is werkzaam als IT Security Consultant bij KPMG IT Advisory. Hij studeerde af op het gebied van Computer Security en heeft meer dan 5 jaar relevante ervaring met IT-beveiliging. Hij is gespecialiseerd in de vele facetten van het beoordelen van IT-beveiliging: ethisch hacken, social engineering, penetratie testen, red teaming en IT-auditing. Klanten zijn onder meer grote bedrijven, zoals financiële instellingen, overheden en petrochemische organisaties. Onlangs heeft Martijn zich verder gespecialiseerd op het gebied van industriële IT-beveiliging (Industrial Control Systems), met een focus op nieuwe ontwikkelingen en bedreigingen.
Encryptie wordt vaak gezien als een doel; de heilige graal van informatiebeveiliging. Steeds vaker zie ik ontwerpdocumentatie met daarin de eis ‘de data in onze app moet worden versleuteld’. Er staat echter niet aan welke eisen de inrichting van de versleuteling moet voldoen en op welke manier de gegevens beschermd moeten worden tegen verschillende dreigingsactoren. Wordt er bedoeld dat de gegevensopslag (data-at-rest) in de app of op de server moet worden versleuteld? Of wordt het verzenden van gegevens tussen zender en ontvanger (data-in-transit) bedoeld? Natuurlijk, wanneer je het goed hebt ingericht, kun je encryptie gebruiken om vertrouwelijkheid van data tot op zekere hoogte te garanderen. Maar daarmee dwing je nog niet de authenticiteit en integriteit van je gegevens af.
Veelgemaakte fout
Een veelgemaakte fout is bijvoorbeeld het ontbreken van zogenaamde ‘certificate pinning’ in apps: de applicatie verifieert dan niet de validiteit van het versleutelingscertificaat (de identiteit van de server) maar controleert alleen of de verbinding versleuteld is of niet. Door zelf een versleutelde verbinding op te zetten tussen de gebruiker en webserver kunnen kwaadwillende personen de informatie onderscheppen en aanpassen, zonder dat de applicatie, gebruiker of webserver dit doorheeft. Bepaal daarom van tevoren wat je wilt beschermen en bepaal daarna hoe je cryptografie daarvoor gaat inzetten. Je zou aan de volgende parameters kunnen denken: symmetrisch versus asymmetrische algoritmes, sleutellengte, ‘stream’ of ‘block’ ciphers, encryptiemodus (zoals ECB, CBC of GCM). Bedenk wel dat elke parameter of optie zijn eigen voor- en nadelen heeft.
Alleen Encryptie biedt geen bescherming
Managers leggen de informatiebeveiliging van de applicatie vaak op het bordje van de ontwikkelaar. Het gevaar van schijnveiligheid ligt dan op de loer, want (de implementatie van) versleuteling is een vakgebied op zich. Net als bij de implementatie van andere software kunnen bugs voorkomen, zoals de Heartbleed, Lucky 13, BEAST of CRIME-kwetsbaarheden. Daarnaast ontstaan problemen doordat protocollen gekoppeld worden die niet met elkaar matchen of verkeerd worden gebruikt, zoals het ‘versleutelen’ van data met de private key van de gebruiker (in plaats van de public key van de ontvanger).
Encryptie heeft mij als professionele hacker tijdens securitytesten nog nooit (langdurig) tegengehouden om de kroonjuwelen van organisaties te kunnen stelen. Met simpele aanvallen (zoals een SQL-injectie of zwak wachtwoord) roof je zo een database leeg of krijg je toegang tot een besturingssysteem en de daarop gebruikte encryptiesleutels. Zoals een van de bedenkers van het RSA-algoritme al stelde: ‘Cryptografie wordt doorgaans omzeild, niet gepenetreerd’.
Zelf knutselen is niet aan te raden
Cryptografie ontwikkelen is een vak apart en het domein van wiskundigen en cryptografen. Veel bedrijven hebben die kennis niet in huis en zelf een encryptiemethodiek ontwikkelen is daarom niet aan te raden. De ontwikkelde encryptiemethodiek bestaat vaak uit verkeerd gecombineerde basisprincipes of protocollen en biedt niet de versleuteling en beveiliging die gerenommeerde leveranciers kunnen bieden. Daarnaast bestaat de kans dat ontwikkelaars aan ‘security through obscurity’ doen. Dat betekent dat ze de algoritmen en protocollen zo ingewikkeld maken of ‘geheim’ houden, dat ze denken dat niemand de beveiliging kan kraken. In de praktijk pakt dit vaak anders uit en heeft een kleine fout grote gevolgen. In plaats van te focussen op zelfgemaakte protocollen zie ik liever dat men zich focust op het gebruik van publieke en open cryptosystemen. Aandachtspunt is daarbij wel de opslag van beveiligingssleutels. Hoe goed zijn die eigenlijk beveiligd? Wie kan er bij? Waar gebruiken we deze sleutels nog meer?
Het beeld van encryptie als de heilige graal voor informatiebeveiliging moet worden bijgesteld. Net als bij het toepassen van de traditionele virusscanner overschat de ontwikkelaar ook de effectiviteit van beveiliging door encryptie. Het gaat er niet om dát je encryptie gebruikt, maar vooral om hoe en met welk doel.
