Risico's en maatregelen bij het gebruik van bibliotheken in bedrijfssysteemconstructie

In de moderne tijd is het gebruik van ‘bibliotheken’ als systeemcomponenten essentieel bij het opbouwen van bedrijfssystemen. Echter, het gebruik van deze bibliotheken brengt ook risico’s met zich mee. Onachtzaam gebruik kan leiden tot problemen en in het ergste geval zelfs tot ernstige schade zoals datalekken. In dit artikel zullen we de risico’s die verbonden zijn aan het gebruik van bibliotheken en de bijbehorende tegenmaatregelen bespreken.

Wat is een bibliotheek (library)?

Bij het bouwen van bedrijfssystemen, is het zeldzaam dat IT-bedrijven alle benodigde programma’s volledig zelf creëren. In plaats daarvan, bouwen ze meestal een basis met ‘kant-en-klare softwarecomponenten’ en vullen ze de ontbrekende delen aan met hun eigen creaties. Deze kant-en-klare softwarecomponenten worden ‘bibliotheken’ genoemd. Het is gebruikelijk om dergelijke bibliotheken te gebruiken bij de ontwikkeling van algemene functies. Algemene functies zijn functies met een hoge vraag in elk bedrijf en elk land, zoals ‘inlogfuncties’ of ‘functies om gegevens uit databases te halen’. Voor deze veelgevraagde functies bestaan er bijbehorende bibliotheken. Aan de andere kant, voor functies die niet algemeen zijn, zoals het voldoen aan unieke klantverzoeken, bestaan er geen kant-en-klare bibliotheken, dus het IT-bedrijf zal deze zelf moeten creëren.

Overigens, er is ook een term die vergelijkbaar is met bibliotheek, namelijk ‘framework’. Daarnaast is er ook de term OSS (Open Source Software). In de context van bedrijfssystemen, is OSS een systeemcomponent en hetzelfde als de bibliotheek waarover we in dit artikel spreken, hoewel het een meer bekende term kan zijn. Echter, in dit artikel zullen we consistent de term ‘bibliotheek’ gebruiken.

Voordelen van bibliotheken: snel en veilig

Er zijn twee redenen waarom systeembedrijven het gebruik van bibliotheken boven zelfontwikkeling verkiezen.

• Het is sneller dan zelfontwikkeling
• Het is veiliger dan zelfontwikkeling

Het is vanzelfsprekend dat het gebruik van kant-en-klare producten sneller is, maar een belangrijk kenmerk is dat ze ook superieur zijn op het gebied van beveiliging. De reden hiervoor is dat bekende bibliotheken continu worden ontwikkeld, getest en gebruikt in productieomgevingen door uitstekende ingenieurs en bedrijven over de hele wereld. Ze hebben maatregelen genomen tegen bekende aanvalsmethoden en we kunnen snelle updates verwachten als er nieuwe aanvalsmethoden worden ontdekt. Aan de andere kant, als je probeert om zelf iets te maken zonder een bibliotheek te gebruiken, kan het nodig zijn om extra moeite te doen, zoals het inlassen van een review door een specialist om beveiligingsproblemen te onderzoeken. In dat geval kan het zijn dat je kosten moet maken om de beveiliging te verbeteren. Vanwege al deze omstandigheden wordt het gebruik van bibliotheken belangrijk als je sneller en veiliger systeemontwikkeling wilt bevorderen.

Nadelen van bibliotheken

Het gebruik van bibliotheken biedt zowel klanten als systeembedrijven grote voordelen, omdat ze systemen snel en veilig kunnen maken. Aan de andere kant zijn er ook bepaalde kosten verbonden aan het gebruik van bibliotheken. Bovendien bestaat er een dilemma: als je geen updates uitvoert, kunnen er ‘kwetsbaarheden’ ontstaan, en als je wel updates uitvoert, bestaat de kans dat het systeem niet meer werkt.

Kwetsbaarheden als er geen updates worden uitgevoerd

Criminelen die uit zijn op het stelen van persoonlijke informatie, creditcardgegevens en bedrijfsgeheimen, zijn dagelijks op zoek naar beveiligingslekken in alle soorten software, inclusief bibliotheken. Deze beveiligingslekken worden in IT-termen ‘kwetsbaarheden’ genoemd. Er zijn talloze gevallen waarin schade is geleden doordat kwetsbaarheden in gebruikte bibliotheken werden uitgebuit. Bijvoorbeeld, ongeveer 200.000 klantgegevens werden gelekt toen een kwetsbaarheid in de Struts2-bibliotheek, die werd gebruikt op de enquêtesite van het Japanse Ministerie van Land, Infrastructuur, Transport en Toerisme, werd aangevallen. Er is ook een geval waarin een ticketverkoopsite die Struts2 gebruikte, mogelijk 32.187 creditcardgegevens heeft gelekt. Het is ook mogelijk dat kwetsbaarheden in een bibliotheek die onbekend waren op het moment van levering van het systeem, later aan het licht komen.

Updates brengen het risico van systeemstilstand met zich mee

In de praktijk zijn er gevallen waarin updates niet kunnen worden uitgevoerd, ondanks het bestaan van kwetsbaarheden. Dit komt omdat er een risico bestaat dat het systeem tijdelijk niet werkt na een update. Omdat bibliotheken geen programma’s zijn die door systeembedrijven zijn geschreven, is het in de praktijk moeilijk om de volledige inhoud te begrijpen. Daarom is het onmogelijk om volledig te voorkomen dat er onverwachte problemen optreden in het systeem na een update, waardoor het systeem tijdelijk niet werkt. Klanten kunnen zich ergeren aan het feit dat het systeembedrijf de inhoud van het geleverde systeem niet begrijpt. Echter, het is een feit dat de kwaliteit en hoeveelheid van de bibliotheken die in moderne systemen worden gebruikt, niet volledig kunnen worden aangepakt door een enkel systeembedrijf. Bijvoorbeeld, er is een bibliotheek genaamd ‘React’, die zeer populair is voor het bouwen van gebruikersinterfaces. Deze bibliotheek is van zeer hoge kwaliteit, gemaakt door Facebook-ingenieurs, en is enorm in omvang, met 195.486 regels code (※1).

Zaken waarin kwetsbaarheden tot een rechtszaak hebben geleid

Er is een vraag over wie verantwoordelijk is als er schade ontstaat door kwetsbaarheden die voortkomen uit een bibliotheek. Een referentiepunt hiervoor is het vonnis van de Tokyo District Court op 23 januari 2014 (Heisei 26). De eiser had de gedaagde, een systeembedrijf, opdracht gegeven om een verkoopsysteem te bouwen. Echter, na de implementatie van het systeem, lekte de creditcardinformatie van eindgebruikers uit door een kwetsbaarheid in het systeem, wat leidde tot een geschil nadat de eiser ongeveer 32 miljoen yen aan schade had geleden door excuses en onderzoeken. In het contract dat de eiser en de gedaagde hadden gesloten, was er een vrijwaringsclausule die bepaalde dat als er schade ontstond door nalatigheid van de gedaagde, de schadevergoeding beperkt zou zijn tot het contractbedrag. Of deze vrijwaringsclausule van toepassing kon zijn, was het punt van geschil. Het vonnis oordeelde dat de gedaagde ernstige nalatigheid had begaan, en dat in gevallen van ernstige nalatigheid de vrijwaringsclausule niet van toepassing is, en beval de gedaagde om een schadevergoeding te betalen die het contractbedrag overschreed.

De gedaagde, als een bedrijf dat zich bezighoudt met het plannen van informatiesystemen, het maken van websites, het ontwikkelen van bedrijfssystemen, enz., en dat zijn bedrijf uitvoert door gebruik te maken van gespecialiseerde kennis over programma’s, en de eiser kan worden geacht het contract voor het systeem te hebben gesloten in vertrouwen op die gespecialiseerde kennis, en het niveau van zorgvuldigheid dat van de gedaagde wordt verwacht is relatief hoog. Gezien het feit dat, zoals hierboven vermeld, als er geen maatregelen zijn genomen tegen SQL-injectie, het mogelijk is dat persoonlijke informatie uit de database lekt als gevolg van een SQL-injectie-aanval door een derde partij, en dit kon worden voorzien door de gedaagde, en gezien het feit dat het Ministerie van Economie, Handel en Industrie en de IPA SQL-injectie-aanvallen noemden als een typische aanvalsmethode tegen webapplicaties en waarschuwden (middelste weglating), het was gemakkelijk om te voorzien dat zo’n situatie zich kon voordoen. Bovendien, aangezien het mogelijk was om het resultaat van de lekkage te vermijden door het gebruik van de bind-mechanisme of het uitvoeren van escape-verwerking, en er is geen bewijs dat suggereert dat het veel moeite of kosten zou kosten om (middelste weglating: technische maatregelen voor het vermijden van verwerking) uit te voeren, kan worden gezegd dat het gemakkelijk was om het resultaat van de lekkage te vermijden. Daarom kan worden gezegd dat de gedaagde ernstige nalatigheid heeft begaan.

Vonnis van de Tokyo District Court, 23 januari 2014

De volgende beschrijving van de Software Information Center Foundation interpreteert dit precedent in de context van bibliotheekkwetsbaarheden.

Op basis van de denkwijze van dit precedent, zelfs als er schade aan de gebruiker ontstaat door een defect (zoals een kwetsbaarheid) in OSS, als de leverancier nalatig is geweest in het aanpakken van de kwetsbaarheid en er opzet of ernstige nalatigheid kan worden vastgesteld, is het waarschijnlijk dat, net als in dit geval, de toepassing van de vrijwaringsclausule (aansprakelijkheidsbeperkingsclausule) beperkt zal zijn en het effect van vrijwaring niet kan worden verkregen. Echter, als een aanval direct na de publicatie van informatie over maatregelen tegen OSS-kwetsbaarheden wordt ontvangen, is het mogelijk dat ernstige nalatigheid niet wordt erkend, zoals het ontkennen van de gemakkelijkheid van het vermijden van resultaten.

Q&A over juridische problemen bij het gebruik van OSS in het IoT-tijdperk [PDF][ja] (pagina 84)

Zoals u ziet, zelfs als het een kwetsbaarheid is die voortkomt uit een bibliotheek, als het een bekende kwetsbaarheid is en het gemakkelijk is om een aanval te voorzien, is het waarschijnlijk dat het als de verantwoordelijkheid van het systeembedrijf wordt beschouwd.

Wat zijn realistischere maatregelen tegen kwetsbaarheden?

Als er een datalek optreedt door opzettelijke of ernstige nalatigheid van een systeembedrijf, wordt verwacht dat er juridisch gezien compensatie kan worden verkregen via een rechtszaak. Echter, vanuit een praktisch oogpunt is het essentieel om in de eerste plaats geen lekken te veroorzaken. Zelfs als je compensatie ontvangt via een rechtszaak, kan het vertrouwen van de eindgebruiker dat verloren is gegaan door het datalek niet worden hersteld. Daarom zijn de volgende twee punten belangrijk:

1. Het sluiten van een onderhoudscontract, inclusief bibliotheekupdates
2. Kwetsbaarheidsdiagnose

Het sluiten van een onderhoudscontract, inclusief bibliotheekupdates

Er zijn contracten voor het bouwen van bedrijfssystemen waarbij alleen de ontwikkeling wordt uitbesteed en contracten waarbij ook het onderhoud wordt uitbesteed. Als je bedrijf geen specialisten heeft die het onderhoud kunnen uitvoeren, is het passend om een onderhoudscontract af te sluiten. In het contract kun je het systeembedrijf vragen om maatregelen tegen kwetsbaarheden, inclusief bibliotheekupdates, en kun je problemen voorkomen door de verplichtingen van het systeembedrijf en de betalingsverplichtingen van de klant duidelijk te maken. Het is noodzakelijk om een contract te hebben waarbij de klant voldoende kosten draagt om een specialist in te huren, terwijl het systeembedrijf verplicht is om als specialist te reageren.

Kwetsbaarheidsdiagnose

Terwijl de hoeveelheid data die systemen verwerken en de eisen aan de UI dagelijks toenemen, blijft het aantal nieuw ontdekte kwetsbaarheden ook toenemen. Daarom is het moeilijk voor alleen het systeembedrijf om volledig te voorkomen dat kwetsbaarheden worden geïntroduceerd. Daarom is een kwetsbaarheidsdiagnose nodig. Volgens de IPA voert meer dan 50% van alle bedrijven en 80% van de grote bedrijven een kwetsbaarheidsdiagnose uit.

Er zijn verschillende soorten kwetsbaarheidsdiagnoses, van gratis tools tot dure handmatige diagnoses. Vooral als je te maken hebt met informatie waarvan het lekken fataal zou zijn, is het essentieel om voldoende kosten te besteden aan maatregelen door een bedrijf in te huren dat gespecialiseerd is in kwetsbaarheidsdiagnoses. Bovendien worden kwetsbaarheden dagelijks ontdekt, dus het is belangrijk om niet alleen op het moment van levering, maar ook na de levering continu een kwetsbaarheidsdiagnose[ja] (P15) uit te voeren.

Samenvatting

In dit artikel hebben we de risico’s en tegenmaatregelen besproken die gepaard gaan met het gebruik van bibliotheken. Hoewel bibliotheken zeer handig zijn, brengen ze ook risico’s met zich mee, zoals kwetsbaarheden die kunnen leiden tot informatie lekken als ze niet worden bijgewerkt. Juridisch gezien kan er een mogelijkheid zijn om compensatie te ontvangen voor informatie lekken als er sprake is van ernstige nalatigheid van het systeembedrijf, maar in de praktijk is het belangrijk om maatregelen te nemen om te voorkomen dat informatie lekken in de eerste plaats gebeuren. Daarom zou u moeten overeenkomen over de tijd die nodig is voor het bijwerken van de bibliotheek en over kwetsbaarheidstests in het contract. Als u geen gebruik maakt van bibliotheken, is het bijna onmogelijk om zowel de deadline als de functionaliteit op het vereiste niveau te bereiken. Om de voordelen van bibliotheken te genieten terwijl u problemen vermijdt, wordt aangenomen dat het noodzakelijk is om overeenstemming te bereiken met het systeembedrijf over de kosten van updates en maatregelen tegen kwetsbaarheden. Om te voorkomen dat uw bedrijf een fatale klap krijgt door informatie lekken, is het belangrijk om niet alleen aandacht te besteden aan elementen zoals functionaliteit, scherm lay-out en prijs, maar ook aan beveiliging vanaf het moment van het contract.