Ja als je dat java overal door de strot word geduwd en overal ingebouwd zit.
Nu is alles lek want dat java rommel zit overal genesteld.
Hoeveel miljard updates zouden er moeten ?, ja ja.

"Ze wil ook van Grapperhaus weten of er alternatieven voor de software beschikbaar zijn"

Deze vraag geeft eigenlijk al aan dat ze niet weten wat ze vragen.
Ik denk dat veel bedrijven die software gebruiken van bepaalde leveranciers nog geen eens weten welke afhankelijkheden deze software heeft of welke ingebouwde oplossingen gebruikt worden... ze kopen een product, niet de onderliggende technieken.

De meeste bedrijven hadden mogelijk nooit van LOG4J gehoord, totdat dit probleem boven water kwam en (er misschien) achter zijn gekomen dat zij dit ook gebruiken.

Dus alsof je kan kiezen voor alternatieve software, dan moet je dus van te voren navragen of de software die je wilt kopen onder water geen LOG4J gebruikt...

Het is vrij zinloos om te weten welke organisaties zijn aangevallen en wat het doel van de aanvallers was.
Een betere vraag was: hebben deze organisaties patches geïnstalleerd. Zo nee, waarom niet?

"Ze wil ook van Grapperhaus weten of er alternatieven voor de software beschikbaar zijn"

Go (golang) natuurlijk. Maar dat antwoord willen ze waarschijnlijk helemaal niet weten.

De alternatieven zijn natuurlijk veilig...

Nu LOG4j, morgen iets anders. Hoe ga je dat ooit bij aanschaf allemaal helder krijgen.

"Kunt u aangeven of componenten die uw software gebruikt, potentieel in de toekomst misschien misbruikt gaan worden door een nu onvoorzien lek?. Zo ja, dan kopen we uw software niet."

Heeft er nog iemand papier en een analoge typemachine ergens liggen?

Zucht. Politici.
Misschien dat de vraagsteller (VVD-Kamerlid Rajkowski) eerst zich eens iets dieper in de materie verdiept.

Oh wacht, het is ICT. Daar is geen inhoudelijke interesse voor bij politici.
Ook al gebruiken ze computers, laptops, tablet en telefoons en allerhande software.
Als in: ze drukken op knoppen. (net als apen hebben ze een kunstje geleerd)

Je klinkt alsof jij dit had aan zien komen........ Achteraf is het mooi wonen toch?

Wat mij meer verbaasd is dat de Log4J nooit echt aan een goede audit is onderworpen. Als Open Source product zou dat toch eenvoudig moeten zijn. Hoe veel onveilige Open Source software wordt er niet wereldwijd gebruikt waar nog nooit fatsoenlijk naar is gekeken en gewoon gebruikt wordt.

Hoe veel ellende gaat er nog meer naar boven komen?

Ze kan beter vragen hoe het kan dat allerlei bedrijven voor miljoenen software diensten aanbieden die afhankelijk zijn van opensource modules die door 1,5 vrijwilliger in de avonduurtjes in de lucht worden gehouden, zonder de code te reviewen en zonder dat er ook maar een cent aan ontwikkeling wordt bijgedragen.
En vervolg vraag, waarom zijn er bij aanbestedingen geen afhankelijkhedenanalyse, code review en bijdragen aan upstream projecten geëist?

"Ze wil ook van Grapperhaus weten of er alternatieven voor de software beschikbaar zijn"

Ik denk dat we met z'n allen sneller updates van (applicaties met) Log4j kunnen installeren, dan een alternatief implementeren.

"Grapperhaus heeft drie weken om de vragen te beantwoorden."

Tegen die tijd zijn de antwoorden die zijn ambtenaren hebben voorbereid al weer achterhaald.

Beste VVD:

Je hebt eerst een lek wat op een gegeven moment ontdekt wordt

Daarna zijn jullie in paniek en komen er patches en/of workarounds.... dat duurt altijd even.

Dan moet je snel patchen om het risico window zo klein mogelijk te houden. Want ja voor de ontdekking kan er al ergens op Interslet een slimme gast er al mee bezig zijn he.

Realiseer je dat een patch niet je reeds binnen gedrongen systemen zuivert...

Oftewel : je loopt altijd achter de feiten aan. De kunst is om het risico window zo klein mogelijk te houden en je systemen goed te controleren.

Dus jullie discussieren daar maar raak in de kamer maar je discussiert over dingen die al 30 jaar zo zijn, alleen het misbruik is nu destructiever (ransomware) en er zijn meer mogelijkheden door het fantastische uitbesteed en cloud beleid... maar ja een ambtenaar gonna be ambtenaar (voor de buhne)

Nee dat zeg ik niet, dat zie ik ook niet in mijn tekst terug dat ik het had zien aankomen.... behalve dit soort kamervragen zie je wel aankomen, altijd na een "dreiging" komt een partij met kamervragen, worden aantal weken later beantwoord, daarna hoor je er nooit meer iets over... zo goed het meestal... dus dat is wel voorspelbaar.

Ik geef alleen aan dat de vraag nutteloos is, aangezien het niet "software" is die je kan vervangen, het is een "onderdeel" van software... De alternatieven kunnen ook LOG4J gebruiken, je weet het simpel niet.
Tevens kan in alternatieven software ook andere vulnerabilities zitten die wel of niet al bekend zijn.
Ook bestaan er scenario's dat sommige software niet eenvoudig te vervangen is.

Door deze vraag te stellen, lijkt het dus eerder een scenario van de VVD dat ze graag laten zien dat ze een vraag willen stellen, maar geen idee hebben wat de inhoud het probleem is.

Ik zou me kunnen voorstellen dat er snel een alternatief voor log4j ontwikkeld kan worden wat 300 ip 300.000 regels code heeft en voor 99.999% van de gebruikers prima is... gewoon messages loggen en klaar.

'Een ambtenaar gonna be ambtenaar."
(Slik)
Met zulke visionaire uitspraken komen we de Ransomwinter wel door, En tsjonge: Wát een doorwrochte toegepaste IT toch met deze kromme anglicismen. Ain't he fit for the twenty second century!' Well... what possibly can go wrong Isn't it fella's?... "Een IT'er gonna be IT'er".

En een politicus is geen ambtenaar.
Dus naast slecht engels, kent die ITer ook het verschil niet tussen politici in de Tweede Kamer en het ambtenarenapparaat.

Schoenmaker blijf bij je leest.

Je snapt duidelijk de boodschap niet. Ambtenaren die achteraf vragen stellen over een digitale wereld die ze jaren aangemoedigd hebben terwijl ze er zelf geen zak van snappen

idd.what possibly can go wrong als je alles digitaliseert en aan Internet hangt L O L....

En dan nu bij lek nr-tje 1.700.000 gaan ze weer wat vraagjes stellen , nou dat gaat helpen denk je niet.

Root cause: "Het is open source dus iemand zal er wel naar kijken, hoeven wij het niet te doen, iemand anders zijn probleem."

Oplossing:
- je snapt de problematiek wat veilig moet zijn
- welke eisen daarbij in te vullen zijn
- neem zelf actie om te zien of die eisen ingevuld zijn.

Alternatief voor software, dat is lastig want 2 keer hetzelfde wiel uitvinden is duur.
In dit geval https://en.wikipedia.org/wiki/Application_Response_Measurement is niet verder gekomen. Iedereen loopt een ander achterna zodat monoculturen ontstaan. Monoculturen verwijderen alternatieven doordat alleshet zelfde moet.

Je snapt werkelijk niet hoe het werkt als je Grapperhaus überhaupt deze vragen stelt. Hou toch op met deze geldverslindende onzin!

Precies dit, ik kan me hier mateloos aan ergeren. Kunnen die Kamerleden zich niet eerst door experts laten informeren voordat ze met dit soort kansloze vragen komen? Bovendien, de enige die dit inhoudelijk kunnen beantwoorden werken nu met man en macht aan een oplossing. Met deze vragen trek je mensen van dat werk af en laat je het probleem dus langer dan nodig voortbestaan.


Ook deze is waar, een beetje softwarepakket bestaat uit tig van bibliotheken en modules. Daar kan je als afnemer van software nooit zelf zicht op hebben en houden. Het NCSC heeft op Github een heel mooi overzicht gepubliceerd met een inventarisatie van veelgebruikte software https://github.com/NCSC-NL/log4shell/blob/main/software/README.md. Kijk eens hoe groot die lijst is! Ook zie je dat na twee weken zelfs de fabrikanten zelf nog steeds aan het onderzoeken zijn of producten van hen getroffen worden door deze kwetsbaarheid.

De vraag "De minister moet ook duidelijk maken welke overheidsorganisaties van Log4j gebruikmaken en welke maatregelen zijn genomen om hen te beschermen." is een slechte vraag omdat deze alleen antwoord geeft op de pleister die nu op dit specifieke geval wordt geplakt. Het zou veel beter zijn om eens energie te gaan stoppen in het nadenken over mogelijkheden hoe je dit soort risico's in zijn algemeenheid kunt voorkomen. Een vraag "Waarom kan een (kleine) fout in een heel specifiek stukje software zo'n grote impact hebben? Wat kunnen we hier aan doen om dit te voorkomen? zouden veel betere vragen zijn.

Hoewel de vraag "hebben deze organisaties patches geïnstalleerd. Zo nee, waarom niet?" in zijn algemeenheid een goede en valide vraag is, gaat deze voor de huidige log4j kwetsbaarheid niet op. De kwetsbaarheid is op 10 december bekend geworden de patch is dacht ik een paar dagen later beschikbaar gekomen. Organisatie zijn met man en macht aan het patchen geweest en toen bleek een week later dat de patch wederom een nieuwe kwetsbaarheid had. Dus toen kon het hele circus opnieuw beginnen.

Het antwoord op jouw voorgestelde vraag zal zijn: "daar waren we mee aan het werk". Ben je ervan bewust dat in hele grote organisaties zoals een ministerie het binnen een week doorvoeren van een patch extreem snel is. Het gaat hier ook niet over één of twee systemen, maar vaak tientallen of zelfs honderdtallen van systemen. Kijk maar eens naar de lijst die NCSC op Github publiceert. Immense lijst....

Dat klinkt simpel, maar de praktijk is weerbarstig. Kijk naar deze log4j kwetsbaarheid: Doe je bij aanschaf een audit, komt er het resultaat uit: "prima, veilig te gebruiken". Bedenkt de ontwikkelaar dat hij log4j gaat uitbreiden met 'enrichment' functies waarmee deze kwetsbaarheid wordt geïntroduceerd (uitleg: https://www.youtube.com/watch?v=5-GkpxbZ9Zw). Je zou dan op elke patch en update een audit gaan uitvoeren. Dat gaat extreem veel tijd en geld kosten.

Daarnaast moet je niet de illusie hebben dat je met een audit elke kwetsbaarheid gaat ontdekken en afvangen.

Kern van het probleem dat we bij Log4j zien, is de zogenaamde 'monocultuur'. Dat komt er simpelweg gezegd op neer dat als heel veel mensen/organisaties dezelfde software gebruiken, ook heel veel mensen gelijktijdig kwetsbaar zijn als er een foutje in deze software zit. Dat is wat we nu met log4j zien, de halve wereld gebruikt is dus het foutje heeft ook direct impact op de halve wereld. An sich maakt het niet uit of het open source of proprietary software is. Het marktaandeel is hier de bepalende factor.

Ja we gaan alle Minecraft spelertjes nu schadeloos stellen.
Oh, wacht even, toch niet....

#corona-proxy

Het is jammer dat je het steeds weer zo framet. Dit ligt namelijk helemaal niet eraan dat het open source is.

Afgaande wat ik op andere fora aan commentaren over de situatie heb gelezen is het versie 2 van Log4j dat het soort toeters en bellen is gaan bevatten die nu voor problemen zorgen. Versie 1 lijkt meer recht voor zijn raap te zijn. Dan ligt het heel erg voor de hand dat heel wat software die Log4j gebruikt dat al is gaan doen toen er een versie zonder die problemen was, en vervolgens de op zich natuurlijk heel verstandige benadering heeft toegepast dat je mee gaat met upgrades en niet op verouderde versies blijft hangen.

Dit is iets dat niet alleen bij open source misgaat, ook bij commerciële software gebeuren dit soort dingen. Ik heb meer dan eens pakketten die mooi begonnen in bloatware zien ontsporen. Het vergt alleen maar een ontwikkelaar, of het nou een open source-project is of een commerciële leverancier, met een sterke gerichtheid op het zo veel mogelijk implementeren van waar gebruikers om vragen, zonder daarbij voldoende te letten op wat nog verstandig is, wat botst met de gekozen opzet, of wat al die verschillende toevoegingen voor interacties met elkaar opleveren. Dat laatste lijkt te zijn wat met Log4j nu is misgegaan.

Zorg dat je voldoende blijft overzien hoe je systemen eigenlijk werken, met andere woorden. Daar ben ik het mee eens.

Bij zoiets als logging moet dat erg meevallen. Om te beginnen bestaat er, ook open source, SLF4J, een logging-interface met afzonderlijke implementaties voor verschillende backends, waaronder Log4j en java.util.logging uit de standaardlibrary van Java.

Ten tweede is logging voor de meeste toepassingen niet iets dat vreselijk veel toeters en bellen nodig heeft, het is in wezen gewoon tekst met een logging-level (debug, info, warning, error etc.). Het is echt niet moeilijk om als dat je behoefte dekt daar zelf een simpele front-end voor toe te voegen aan je applicatie die niets anders doet dan de call doorgeven aan de gebruikte logging-backend. Dat betekent dat overstappen op een andere backend op maar één plek in je programmacode een wijziging oplevert. Dit zou elke programmeur moeten kunnen bedenken en implementeren.

Zelfs als dat allemaal niet is gebruikt lijkt dit me niet de moeilijkst denkbare conversie. Als het inderdaad om tekst met een logniveau gaat dan is het vervangen van de ene backend door de andere in wezen een soort geavanceerde zoek-en-vervang-actie door je hele code base heen. Als moderne IDE's daar niet al goede hulpmiddelen voor bieden (daar heb ik niet zo'n zicht op, ik werk zelf ouderwets met vim) dan is zelf een programma schrijven dat de conversie doet niet overdreven moeilijk. Ik heb in mijn loopbaan meerdere van dat soort conversies meegemaakt. Niet ideaal als het in zo'n noodgeval eigenlijk vandaag al klaar moet zijn, maar er zijn problemen die een stuk moeilijker op te lossen zijn.

Dat heet standaardisatie. Een standaard levert geen monocultuur op, het helpt die juist voorkomen. Het staat namelijk meerdere compatibele implementaties toe waaruit je kan kiezen. Een monocultuur heb je als iedereen gebonden is aan dezelfde implementatie.

Standaards staan niet stil, ook die ontwikkelen zich om nieuwe behoeftes te dekken. Dat gaat langzamer dan bij niet gestandaardiseerde interfaces waarbij elke leverancier zijn eigen gang kan gaan zonder rekening te houden met compatibiliteit met anderen. Dat kan kortetermijnvoordelen opleveren, maar de prijs die je daarvoor betaalt is supplier lock-in.

Het zijn POLITICI die die domme vragen stellen.
Niet opgelet op de middelbare school blijkbaar.

Of snap jij misschien niet hoe het werkt? De vragen worden niet aan de persoon Ferd Grapperhaus gesteld maar aan de Minister van Justitie en Veiligheid. Er is bij (veronderstelde) ongeschiktheid van de persoon geen alternatieve Minister van Justitie en Veiligheid, dat is het aanspreekpunt waar ze het mee te doen hebben, dus die krijgt de vragen.

De regering is de uitvoerende macht, en de kamer zit er om die te controleren. Als je uitvoering controleert dan stel je ook vragen waar je de antwoorden al van weet en andere "domme" vragen. Ze dienen namelijk niet alleen om de informatie te krijgen waar de vraag over gaat, maar ook om te controleren of de uitvoerder alles op een rijtje heeft en zijn zaken op orde heeft.

Haha tegenwoordig kun je POLITICI rustig ambtenaren noemen. Veel overleggen en weinig voor elkaar krijgen en veel geld van de brugers over de balk gooien. Op ICT gebied zijn ze beiden ook super goed, dat blijkt wel op deze site als je rustig door alle nieuwsitems blader.

Precies dit. Veel bedrijven freeloaden op Open Source software. Dit is toevallig een module die door een man of 6 geschreven is en "plotseling" heel veel gebruikt is door veel commerciële partijen. Dat er niemand van zo'n bedrijf ooit gezegd heeft: hé, laten we dit spul dat we gewoon gratis van github clonen eens toetsen middels een (secure) code review voordat we deze software embedden en de resultaten en wat centen aan dat project doneren zodat ze de boel kunnen maintainen. Uit de NCSC-NL github lijst haal ik 97 unique vendors die een vulnerability moeten patchen, waaronder Canon, Cisco, Hitachi, HPE, IBM, Intel, Microsoft, Philips, Red Hat, Salesforce en SUSE. Niet de kleinsten en ook een aantal die al een (grote) bijdrage leveren aan Open Source, die vind ik persoonlijk wat minder verwijtbaar, je kunt niet elk OSS project ondersteunen of sponsoren.

Precies of biedt ze een baan aan zoals Bram Moolenaar (vim) of Guido van Rossum (Python) zodat ze het betaald kunnen onderhouden (in dit geval Google)

Dat klopt, een en ander vele jaren gevolgd. Er waren andere alternatieven via IBM HP meer als opvolger van SMF.
Wat ik zag gebeuren dat iedereen iedereen gaan napraten dat open source en goedkoper en veiliger zou zijn met het argument dat jij framing noemt. Uit kostenbesparing wat kopieren van andere zonder zelf een gesegmenteerde aanpak (DMZ) te overwegen is sneller in het opleveren van een resultaat. Ik heb het niet over open source ja/nee als argument maar om het kosten baten gebeuren waarbij veiligheid als iets voor anderen neergezet is.

Ik ook, er blijft gewoon een afweging wat verantwoord is en wat niet met technisch inzicht. De besllissers ziiten op posities zonder technisch inzicht meer geleid door commerciële zaken.

Kijk daar hebben we een gelijkgestemd inzicht. Blijft lastig dat vanuit techniek geen beslissingen doorgezet kunnen worden.

Technisch zijn die er wel, ik gaf ook een voorbeeld. Nu moet je dat tot een geheel zien te krijgen met een aansluiting op een Siem. Er zijn vele monitor tools zoals nagios nmon prometheus ook die worden te vaak weer nagebouwd in een pakket. De reden het ontbreken van interfaces of de noodzaak van een shell.


Klopt, het is vaak sneller en eenvoudiger om zoiets er naast te zetten. Je loopt meteen tegen de weerstand aan (managers beslissers) dat ze standaard oplossingen van buiten willen.
Probeer eens buite Cef te komen https://community.microfocus.com/cfs-file/__key/communityserver-wikis-components-files/00-00-00-00-23/3731.CommonEventFormatV25.pdf Een systeem wil men monitoren als security eis.

Helaas wordt uit kostenbesparing met standaardisatie door beslissers dezelfde implementatie geëist. Gevolg monocultuur
Ik zou (jij ook) voor een eenvoudige controleerbare interface gaan en de implementatie variabel laten.

Klopt en we zitten weer op kosten baten als je dat wilt vermijden.

Jaja... En na een paar maanden is die ook weer ge-explodeerd naar 3000+ regels, met nieuwe verse bugs.
Deze https://xkcd.com/927/ hoort daar ook bij...

Karma4 komt met een 'root cause' die causaal helemaal niet gerelateerd is aan het artikel waar hij op reageert. Een nieuw dieptepunt dat misschien voortkomt uit een aanhoudende verwarring over wat het woord correlatie betekent. Hoewel, er is zelfs geen sprake van een correlatie tussen het ontstaan van het log4j probleem en open source software.

Het enige wat je over open source kan zeggen in de context van deze discussie is dat de afhandeling van het probleem vele, vele malen moeilijker zou zijn geweest als log4j closed source was geweest.