Elke werkdag behandelt Computable een onderwerp waarover lezers kunnen discussiëren. Vandaag over de valkuil waar security oh zo vaak in tuint: ‘zou niet moeten’.
Security is niet alleen een kwestie van gedegen ontwikkelen en goed testen. Het komt in de praktijk maar al te vaak óók neer op erkennen. Daar schort het nogal eens aan. Niet eens zozeer qua erkenning door leveranciers van vondsten die door externe onderzoekers worden claimen. Het gaat om het security-equivalent van Steve Jobs’ reactie op ‘Antennagate’: Je houdt het verkeerd vast. Dit gebrek aan erkenning speelt ook bij security en daar bij flink technische kwesties.
Zo reageerde een van de makers van CryptDB op een ontdekte kwetsbaarheid dat ‘dit niet de manier is waarop CryptDB gebruikt zou moeten worden’. Daarbij verwees zij de ontdekkers naar de oorspronkelijke paper over deze encryptietool voor databases. Echter, de Microsoft-onderzoekers die de kwetsbaarheid hebben gevonden, wijzen juist op die paper om hun gelijk te halen. ‘Onze analyse is gebaseerd op één van hun eigen voorbeeldtoepassingen.’ Security valt in de ‘zou niet moeten’-kuil. Wat vind jij?
De vraag is wat je met erkenning van het probleem bereikt als fabrikant.
In principe heeft elke security tool kwetsbaarheden die kunnen worden geexploiteerd en is het gewoonweg niet mogelijk om een produkt te maken dat 100 procent veilig is. Fabrikanten van security produkten voeren een continue bewapeningswedloop met hackers.
Een security produkt wordt aangeschaft om een reductie van het risico van te bewerkstelligen en niet om 100 procent veiligheid te waarborgen.
Security begint en eindigt bij de gebruiker. Wanneer een product niet veilig is wordt het gewoon niet gebruikt. De gebruiker kan de veligheid van een product echter niet altijd goed beoordelen. Zeker niet wanneer de veiligheid pas na een tijdje niet blijkt te voldoen.
In de techniek wordt daarom in principe met intrinsiek veilige producten gewerkt, behalve de computertechniek. Dat zegt iets over de computertechnici. (Voor de goede orde: Ik wijs hierbij ook naar mijzelf). Onveiligheid kan veel beter worden voorkomen. Zolang bv Mathijs van Nieuwkerk in “De Wereld Draait Door” de Silicon Valey vrijbuiters als voorbeed stelt voor de ontwikkelingen in NL, moeten we het niet gek vinden dat onze eigen informatie misbruikt voor doeleinden waarvoor we het niet beschikbaar zouden stellen.
Er is echter wel degelijk een intrinsiek veilige Informatie en Communicatie Technologie mogelijk. Die moet dan wel gemaakt worden. Zolang dat niet gebeurt blijven we dit soort discussies houden. Een discussie over de ernst en de kosten van symptomen. Terwijl de discussie over de oorzaken er van blijft liggen. Die oorzaak is de chaotische groei van software, tegenwoordig apps, waarbij andere belangen dan die van de eindgebruiker nog steeds het uitgangspunt vormen…
Inderdaad een goede vraag. Wat bereik je met het erkennen van een probleem door een klant of andere externe organisatie.
Bij alles wat je leest of aangedragen krijgt moet je je natuurlijk afvragen wat het belang is van de schrijver of aandrager. Maar als iemand je laat zien dat je iets niet zo goed hebt gedaan, compleet met bewijsmateriaal, dan getuigt het van grenzeloze arrogantie om te zeggen dat er niets aan de hand is.
Natuurlijk is schier het onmogelijk om 100 procent veilige software te maken. En wat vandaag veilig is is dat morgen niet meer. Al was het maar omdat met de rekenkracht van morgen de encryptie van vandaag kan worden gekraakt. Maar dat kan nooit een argument zijn om zo’n issue niet te erkennen. Al helemaal niet als het om beveiligingstools gaat.
Hoe goed je ook denkt te zijn beveiligd met de meest geavanceerde encryptiemethodieken, iedere keer komen er weer nog slimmere wetenschappers of hackers die onveiligheden ontdekken.
Het is en blijft dus een kat-en-muis spelletje. Het feit dat de inlichtingendiensten nu zo zenuwachtig worden van de komst van Quantumcomputers zegt ook alweer genoeg over dat absolute security niet bestaat.
Zelfs wordt door sommige wiskundigen de alom geroemde One-Time Pad methode kraakbaar geacht door brute rekenkracht vanwege de beperkingen in teken en cijferreeksen. Niemand kan nl. bewijzen dat een algoritme niet kan worden gekraakt in een bepaald tijdsbestek.
In de gegeven voorbeelden overschatten de makers van de securitymaatregel zichzelf en staan niet meer open voor kritiek. Vaak ook al om imago verlies en eventuele aansprakelijkheid als gevolg van het falen.
We zien het ook bij Password beveiliging. De eerste beveiliging bestond door het onzichtbaar maken van het invoerveld met asteriks. Daarna moest het wachtwoord worden versleuteld met hashtechnieken, die ook niet veilig genoeg zijn. Nu wordt two factor authentication de norm. Ook daarover zijn wijfels hoe lang dat stand houd.
Kortom, het blijft mensenwerk, zowel het bedenken van veiligheid als het kraken ervan. Het lijkt erop dat de Security “Einstein” nog geboren moet worden.
Een tester moet juist proberen te ‘zieken’, oftewel als een soort saboteur t.o.v. een ontwikkelaar optreden. Het lijkt erop, dat bij CryptDB en de Iphone 4 onvoldoende is gebeurd.