Na de Heartbleed-ophef begin dit jaar, blijven oplossingen voor dit en andere problemen nog steeds uit.
Het Heartbleed security probleem schokte eerder dit jaar de internetwereld, met welhaast apocalyptische doembeelden inzake diefstal van gebruikersgegevens. Uit de berichtgeving bleek in ieder geval hoe weinig (financiële) middelen werden besteed aan de bouw en het onderhoud van soms uiterst cruciale onderdelen van het internet, zoals alom aangewende bibliotheken van softwarecode.
Nog steeds te weinig geld
Op het recente Black Hat event werd toegelicht van welke bibliotheken op grote schaal gebruik wordt gemaakt, hoezeer ze lijden onder securityproblemen en in welke mate ze worden ondersteund.
Daaruit bleek onder meer dat ondanks beloften van geld de OpenSSL-bibliotheek, die aan de basis van het Heartbleedprobleem lag, nog steeds over te weinig middelen beschikt, onder meer met het oog op een optimale veiligeheid. Zo werd berekend dat er minstens zes voltijdse krachten nodig zijn voor een degelijke ondersteuning, maar met de verzamelde middelen konden slechts twee voltijdse ontwikkelaars worden aangenomen.
Een ander probleemgeval bleek de FreeType-bibliotheek in meer dan een miljard toestellen (iOS, Android, ChromeOS, Ghostscript – een Postscript interpreter in printers). In de voorbije jaren werden meer dan 50 zwakheden gevonden in FreeType, die onder meer mogelijkheden boden tot het overnemen van smartphones (iPhones), denial-of-service aanvallen en dies meer.
Securityproblemen doen zich ook voor in frameworks voor softwareontwikkeling, hoewel daar vaak meer personen aan meewerken.
Aansprakelijkheid
In een discussie rond de presentatie op Black Hat, werd er onder meer op gewezen dat softwarebouwers – commerciële ontwikkelaars en ontwikkelaars in bedrijven – al te vaak geen aandacht besteden aan de securitykwaliteiten van bibliotheken of frameworks, of geen weet hebben hoe die middelen op een veilige wijze aan te wenden. Vaak worden security-patches in de bibliotheken en frameworks niet opgevolgd, en pas bij nieuwe versies van een stuk software doorgevoerd.
In de discussie gingen dan ook stemmen op om softwarebouwers aansprakelijk te maken voor securityproblemen in hun software, en eventueel zelfs te laten opdraaien voor de schade die door dergelijke lacunes wordt veroorzaakt. Aangezien dergelijke suggesties op harde weerstand van de software-industrie zullen stuiten, werd onder meer gewezen op mogelijke stappen die personen die software kopen of laten ontwikkelen kunnen nemen. Zo kan eventueel worden geëist dat de software door een derde partij wordt geauditeerd inzake security. Of men kan in contracten op eigen initiatief clausules laten opnemen inzake aansprakelijkheid, zoals onder meer verwoord in de OWASP Secure Software Contract Annex – een absolute aanrader.
