Security (b)log: sbom

vrijdag 2 februari 2024

Ingrediënten

Foto van auteur

Ingrediënten: witte bonen 61%, water, tomatenpuree 16%, suiker, zeezout, natuurazijn, maiszetmeel, natuurlijk kruidenaroma. Aldus het achteretiket van de pot die aan de voorkant ‘witte bonen in tomatensaus’ heet. Past dit product in een zoutarm dieet? Geen idee, want daar hoeft mijn gezondheid zich gelukkig niet druk om te maken. Maar als het ooit wel nodig zou worden, dan wil ik graag op het etiket van welk product dan ook lezen of er zout in zit, en liefst ook nog hoeveel.

Het is puur toeval dat ik net als vorige week wederom in de conserven zit – ik overweeg geen overstap naar die industrie, noch ben ik gevraagd om hun producten te promoten (eet vooral ook verse groente mensen!). Maar ik ben nu eenmaal van de metaforen, en zo’n pot groente blijkt dan een dankbaar object te zijn.

Meestal zal het je een biet wezen wat er behalve witte bonen en tomatensaus nog meer in een pot witte bonen in tomatensaus zit, behalve als je een specifieke reden hebt, zoals een doktersadvies. En dan ben je blij dat het allemaal op het etiket staat.

En wat blijkt nou? Met ICT is het net zo. Zolang alles goed gaat, boeit het niemand welke programmeertaal, welk framework en welke libraries er zijn gebruikt, welke open source-componenten erin zitten of op welk platform het systeem draait. Maar als plotseling begint rond te zoemen dat een bepaald, breed gebruikt ingrediënt een ernstige kwetsbaarheid bevat, dan wil je opeens heel graag weten of dat ingrediënt in jouw systemen voorkomt. Want je wilt zo nodig overstappen op een zoutarm dieet, of je wilt het zeezout vervangen door gewoon keukenzout, of misschien moet je wel – al dan niet tijdelijk – overstappen op sperziebonen.

Wat voor levensmiddelen het etiket is, dat is voor ICT de SBOM: de Software Bill of Materials, de lijst van componenten die in het product zijn verwerkt. Toen in december 2021 bekend werd dat Log4j een ernstige kwetsbaarheid bevatte, was de wereld in rep en roer. Log4j is namelijk zo’n soort zout, dat in heel veel producten wordt gebruikt. Als je op een dag hoort dat er verontreinigd zout is gebruikt, dan wil je als fabrikant meteen weten welke van jouw producten dat zout bevatten, zodat je de juiste producten uit de supermarkten kunt terughalen en je productieproces kunt stoppen totdat je over een lading schoon zout kunt beschikken.

Nou kwam mij ter ore dat de beheerders van sommige systemen ervan uitgaan dat Security wel weet welke componenten in welk product zitten, en bij hen alarm slaat als er iets aan de hand is met zo’n component. Maar zo werkt het natuurlijk niet. De Nederlandse Voedsel- en Warenautoriteit weet ook niet in welke producten de conservenfabriek zout verwerkt. Ze kunnen alleen alarm slaan als er een slechte batch is geleverd. Het is dan aan de fabrikant om na te gaan in welke producten dat zout kan zijn terechtgekomen en de juiste maatregelen te treffen. Bij ons, in de ICT, is het net zo. Security weet als er iets mis is, maar de beheerder moet weten of zijn systeem daardoor wordt geraakt en of hij in actie moet komen. Natuurlijk zal er bij grote toestanden altijd coördinatie plaatsvinden, maar je blijft wel verantwoordelijk voor je eigen systeem.

Het is de oplettende lezer wellicht opgevallen dat ik het hierboven steeds over systemen en producten heb, terwijl de s in SBOM toch voor software staat. Maar waarom zou je een ingrediëntenlijst beperken tot software? Ook hardwarecomponenten kunnen kwetsbaar zijn, zoals Meltdown en Spectre, allebei kwetsbaarheden in bepaalde CPU’s, in 2018 pijnlijk duidelijk maakten. Je wilt dan natuurlijk wel weten of jij apparatuur hebt waar de kwetsbare processoren in zitten. Nou, gelukkig bestaat ook zoiets als de HBOM: de Hardware Bill of Materials. Liefst zou je daar alle componenten in terug willen zien, tot op het kleinste chipje. Ik weet alleen niet of fabrikanten daar met alle plezier aan willen meewerken, want de concurrenten lezen natuurlijk mee. Dat hoeft niet per se een probleem te zijn, als je erop aankunt dat de fabrikant zelf zijn BOM’en op orde heeft én daar ook zijn klantenbestand aan heeft gekoppeld én ook de communicatie goed is ingericht. Dat kun je allemaal contractueel afspreken. In je CBOM.

En in de grote boze buitenwereld …

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.