“Heeft u uw koffer zelf ingepakt?”

Ken uw software stack!

Iedereen kent de vraag wel bij de douane als op vakantie gaat: ”Heeft u zelf uw koffer ingepakt? Weet u zeker dat niemand anders er iets in heeft kunnen stoppen voordat u hem afsloot?”. Natuurlijk weet je zeker dat niemand met je spullen heeft kunnen rommelen, maar wie heeft nou af en toe niet een klein beetje twijfel?

Een soortgelijke vraag zou uw CIO, leidinggevende of accountant kunnen stellen als er weer eens een hack van een gemeente, overheidsinstelling of groot bedrijf in het nieuws komt; “Weten wij zeker dat dit lek ook niet in onze software stack zit?”. Ik vrees dat u het antwoord schuldig zult blijven zeker als u bedenkt dat, volgens een recent onderzoek, 78% van de code van uw software uit open source code bestaat en dat 81% daarvan minimaal één kwetsbaarheid bevat. We hebben de laatste maanden al met zekere regelmaat berichten gezien over open source software waar de nodige problemen mee waren, xdus nieuw is dit niet, maar toch…

Componenten die meer dan 2 jaar achterlopen

Het Synobsys Cyber Security Center heeft onlangs het rapport “THE 2022 OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT” gepubliceerd en de bevindingen moeten iedereen die een veilige softwarestack een hoge prioriteit geeft de nodige hoofdpijn geven. Zelfs in een “gesloten” industrietak als de gezondheidszorg heeft >93% van de codebase open source componenten. Netjes verwerkt in een read.me bestand of addendum aan het contract worden veel open source componenten met name genoemd, soms zelfs met het type licentie waaronder het beschikbaar is gesteld door de community. Maar lang niet allemaal en al helemaal niet wat het beleid van de leverancier is aangaande updates en nieuwe releases. Als je je dan bedenkt dat, in bovenstaand onderzoek, regelmatig bleek dat OS componenten meer dan 2 jaar achterliepen op updates of zelfs out-of-date (niet langer ondersteunde) versies bevatten dan moet de ernst van het probleem zo langzamerhand toch wel doordringen.

Weet u welke versie(s) van OpenSSL er op dit moment in uw softwarestack gebruikt worden?

Ook al weet u misschien niet van wat voor onbetrouwbare software uw organisatie afhankelijk is, u kunt er verzekerd van zijn dat criminelen dat wel weten. Zonder iets af te doen aan de kwaliteit van open source is duidelijk dat er een nieuw monster is geschapen; een software supply chain die uit zoveel verschillende componenten bestaat dat niemand meer weet of de software-stack (commercieel en open source) nog te vertrouwen is. Een voorbeeld: OpenSSL is een open source component dat zeer veel gebruikt wordt door softwareleveranciers. Van de OpenSSL code waarvan de oorsprong teruggaat naar 1998(!!) zijn meer dan 8000 forks gemaakt (een copy waarop verder ontwikkeld is) en er zijn ongeveer 1500 openstaande problemen. De nieuwste versie dateert van 3 mei 2022 en bevat belangrijke security fixes. Weet u welke versie(s) van OpenSSL er op dit moment in uw softwarestack gebruikt worden en of die laatste fixes daar ook inderdaad in zijn verwerkt? Krijgt u gegarandeerde updates van al uw software leveranciers en hoe weet u dat zij zich daar aan houden?

Er is eigenlijk maar één oplossing voor dit probleem: U neemt alleen nog maar applicaties en diensten af vanuit de cloud. De aanbiedende partij is verantwoordelijk voor de softwarestack en u hoeft zich daar geen zorgen meer over te maken. Natuurlijk moeten er wel afspraken gemaakt worden met de aanbieders over hun patch- en release beleid.

Helaas zal het voor de meeste organisaties nog jaren duren voordat het zo ver is en in de tussentijd wordt dit probleem alleen maar groter; er wordt meer en meer open source code gebruikt en cybercriminelen zullen steeds sneller gebruik maken van de kwetsbaarheden in al die verschillende componenten van de software stack. Dus zult u andere maatregelen moeten nemen voor de software die u nog gebruikt:

1. Het beheer wordt uitbesteed aan externe (specialistische) partijen. Zo’n gespecialiseerde partij beheerd een specifiek gedeelte van de software en dat maakt het eenvoudiger om te zorgen dat deze software stack zo up-to-date mogelijk is. Denk hierbij aan complexe security oplossingen, monitoring software of complexe integratie software als iPaaS omgevingen of API Gateways.
   
2. U neemt functionaliteit af als dienst zodat u de software helemaal niet meer in eigendom hoeft te nemen. Goede voorbeelden hiervan zijn bijvoorbeeld het monitoren van security events of het volledig uitbesteden van API en ESB koppelingen en alle software die daar bij betrokken is. In het geval van security monitoring heeft u de voordelen van de zeer specialistische kennis en ultramoderne software stack van uw partner, en als u samenwerkt met een integratie partner kunnen uw ontwikkelaars zich focussen op functionaliteit terwijl specialisten zich bezig houden met veilige integraties en alle problematiek en software die dat mogelijk maakt.

Het is een gegeven dat iedere softwarestack een bonte verzameling is van code waarvan niet altijd duidelijk is hoe up-to-date en veilig deze is. Daar zult u met uw leveranciers afspraken over moeten maken maar tegelijkertijd moet u beslissen of een gedeelte van deze verantwoordelijkheden elders neergelegd kunnen worden. En zelfs als u daar gedeeltelijk in slaagt blijft er nog genoeg over om u zorgen over te maken.