vrijdag 17 december 2021

SBOM


 

Als computertoestanden al een week steeds weer opduiken in het algemene nieuws, zoals het Journaal, dan weet je dat het ernstig is. Een maand geleden fluisterde Alibaba, het Chinese internethandelsbedrijf, iets in het oor bij softwarebedrijf Apache: ze waren een foutje tegengekomen in het programma log4j.

Dat ‘fluisteren’ noemden we vroeger responsible disclosure, tegenwoordig wordt de chiquere term coordinated vulnerability disclosure gehanteerd. De inhoud van de boodschap blijft gelijk: iemand ontdekt een kwetsbaarheid in een systeem en meldt dat aan de maker of eigenaar ervan. Dat heette dus vroeger ‘verantwoord’ en nu ‘gecoördineerd’, maar je zou het ook gewoon ‘netjes’ kunnen noemen. De alternatieven zijn namelijk minder fraai: de ontdekker zou zijn vondst aan de grote klok kunnen hangen, waarna hackers met minder goede bedoelingen er misbruik van zouden kunnen maken. Of hij houdt het stil en zoekt zelf een manier om er zijn voordeel mee te doen. Dat is een favoriete hobby van inlichtingendiensten, maar je kunt ook criminele toepassingen bedenken. Zolang de eigenaar van een brakke website of de producent van kwetsbare software geen weet heeft van de kwetsbaarheid, komt er ook geen verbeterde versie. We spreken dan van een zero-day vulnerability.

In het geval van de kwetsbaarheid in log4j is dus zo’n nette melding gedaan, maar dat betekent niet dat er dan meteen een oplossing is. Anderen hebben de kwetsbaarheid waarschijnlijk ook ontdekt en hebben haar gebruikt om in systemen binnen te dringen. Een spannend moment is altijd als een fabrikant roept: “Hé, er is een nieuwe versie van mijn programma, want de oude bevat een foutje.” Dat is het startschot voor een race tussen hackers en de gebruikers van dat programma. De hackers weten dat de oude versie kwetsbaar is, en ze weten ook dat gebruikers niet altijd snel kunnen of willen updaten, en soms niet eens weten dat ze dat zouden moeten doen. Die tijd kunnen ze gebruiken voor hun snode plannen. En even tussen haakjes: “gebruikers”, dat zijn in dit geval niet jij en ik – de gewone computergebruikers – maar organisaties die log4j gebruiken in hun eigen software en online systemen.

Het is allang niet meer zo dat een programmeur zijn eigen programma’s van A tot Z zelf schrijft, zoals wij dat in de jaren negentig nog deden met onze COBOL-programma’s. Nee, tegenwoordig worden er allerlei modules van anderen gebruikt. Want waarom zou je steeds weer zelf het wiel moeten uitvinden? Sommige van die modules kun je kopen, andere kun je gratis vinden in de wereldwijde community van de open source software. Het idee daarachter is dat we alles met elkaar delen én elkaars werk kunnen controleren. Log4j wordt onder een open source-licentie beschikbaar gesteld, wat inhoudt dat iedereen het vrijelijk mag gebruiken, aanpassen en verspreiden.

Een groot probleem bij deze kwetsbaarheid (die overigens de naam log4shell heeft) is dat vaak niet bekend is wáár het zeer populaire log4j overal wordt gebruikt. Het is niet zo’n programma als Word of Outlook dat iedereen kent; het is een softwarecomponent voor logging, het vastleggen van systeemactiviteiten. Vergelijk het voor het gemak maar met de aloude scheepslogboeken, waarin wordt bijgehouden wie wat wanneer heeft gedaan. Logging is belangrijk om bij geconstateerde fouten uit te kunnen pluizen waar het mis ging. Log4j is verweven met allerlei systemen. Sommige (veel?) organisaties weten niet eens dat deze software ergens in de ingewanden van hun systemen draait. En organisaties, die dat wél weten, hebben vaak geen overzicht van wáár het dan overal in zit. Het is een heidense klus om dat alsnog in kaart te brengen. Voeg daaraan toe de druk van de race tegen hackers en je hebt een mooi recept voor stress. Veel systeembeheerders en softwarebouwers hebben deze week lange dagen gemaakt om naar log4j te speuren en over te stappen op de nieuwe versie (want die is er sinds 9 december).

In oktober gaven Allan Friedman en Bart van Riel op de One Conference in Den Haag een presentatie over de Software Bill of Materials. De SBOM is een digitale lijst van componenten waaruit een computerprogramma bestaat. Zoals op een pak hagelslag of een fles shampoo precies staat wat erin zit, zo bevat de SBOM alle ingrediënten van de desbetreffende software. Als dan op een kwade dag één van die componenten een kwetsbaarheid blijkt te bevatten, dan is het een peulenschil om na te gaan waar die component overal in zit. Althans, in theorie – het veronderstelt namelijk wel dat de SBOM compleet en actueel is, en dat is een hele opgave. Het mechanisme werkt ook alleen als iedereen meedoet. Zoals Friedman zo mooi zei: “We’re all-in the supply chain. Most of us somewhere in the middle.” En dat betekent dat je er niet bent met het SBOM’en van je zelfgemaakte systemen – je bent ook afhankelijk van je leveranciers om een volledig beeld te hebben. En jouw afnemers zijn weer afhankelijk van jou.

Voor het bestrijden van log4shell zouden SBOM’s zeer welkom geweest zijn. Voor sommige organisaties misschien wel cruciaal. Als je momenteel strijdt tegen log4shell, dan heb je daar nu weinig aan. Maar als het straks weer rustig is, doe je er goed aan om je eens in SBOM te verdiepen. De website van CISA, waar Friedman deze kar trekt, is een goed startpunt daarvoor. En oh ja, zet je in de tussentijd schrap voor ransomware-aanvallen als gevolg van log4shell.

De Security (b)log keert na de kerstvakantie terug.

 

En in de grote boze buitenwereld …

 

Geen opmerkingen:

Een reactie posten