Klinkt als: 'Wij hebben alleen maar de software beschikbaar gesteld, anderen (zonder expertise) hebben het verkeerd gebruikt."

Kreukelzones met gescheiden segementen, het zou standaard moeten zijn naast een rijbewijs.

Dan spreek ik nu maar voor alle zakelijke en particuliere bankrekeninghouders, waarvan er particulier alleen al bij ABN/AMRO en ING zestien miljoen (16.000.000) zijn in Nederland:

In welke mate is er een vervolgkwetsbaarheid voor ons?
Hoe 'druk' moeten wij ons maken?
Of is het voor ons maar een storm in een glas water?

Wie kan hier iets zinnigs over zeggen?

Dank, namens alle bankrekeninghouders.

Apache =! Log4J

Apache webserver is wat anders dan Apache log4j. We hebben de banken er niet over gehoord, dus zullen ze wel kwetsbaar zijn geweest.

Geen idee of het zinnig is, maar laat ik het eens proberen.

Het juiste antwoord is "dat hangt er vanaf". Zoals bijna alle vragen op gebied van informatiebeveiliging dit antwoord hebben. In het kort (in niet-formele bewoordingen): IT systemen introduceren zwakheden. Zwakheden in de software zelf, zwakheden in de gekozen softwarearchitectuur, zwakheden in (beheer)processen, zwakheden in het IT (beveiligings)beleid, noem maar op. Die zwakheden moeten worden geadresseerd via maatregelen. Die maatregelen zorgen ervoor dat de kans en/of impact van een bedreiging wordt beperkt, en dat je als team, business unit of bedrijf binnen je risk appetite blijft.

Soms gaat dit goed. Banken hebben niet voor niets personeel rondlopen zoals software architecten, risk managers, IT security medewerkers en applicatieteam medewerkers met kennis van zaken. Je hoopt dat die hun werk goed doen en de problemen het hoofd weten te bieden waar ze mee te maken hebben. Ik heb daar in het verleden een paar voorbeelden van gegeven: https://www.security.nl/posting/665955#posting665968. Die lijst kan uitgebreid worden met nog veel meer problemen. Denk b.v. aan bedrijfsonderdelen die zeer gericht zijn op compliance ("het volgen van de regeltjes en zetten van vinkjes") in plaats van security ("zaken écht veiliger maken door de implementatie, verificatie en continue controle van de juiste maatregelen"), bedrijven met zwak lifecycle management waardoor niet-ondersteunde software aanwezig is die is geleverd door een bedrijf dat niet meer bestaat, etc.

De vraag is nu: hoe zit dit bij banken? Het antwoord, en ik spreek nu voor de financiële instellingen waar ik de afgelopen 20 jaar heb gewerkt: het is op veel plekken niet goed geregeld. Maatregelen worden niet goed nageleefd, maatregelen worden half ingericht (hetgeen de beheerders soms wel en soms niet weten), maatregelen worden helemaal niet ingericht, controle op de juiste implementatie van maatregelen is niet aanwezig, noem maar op. Is dat erg? Dat ligt eraan. Ik kan me voorstellen dat het risico van een kwetsbare server beperkt is wanneer b.v.
- een kwetsbare server fysiek is afgescheiden van het netwerk,
- een kwetsbare server in een netwerksegment staat waar de juiste firewall regels voor zijn geconfigureerd,
- een kwetsbare server software heeft draaien die technisch de zaken op orde heeft (b.v. MFA en een 4-ogen principe voor het overboeken van geld),
- een kwetsbare server een vorm van IPS heeft draaien die aanvallen tot op zekere hoogte tegenhoudt,
- ...

Allemaal niet perfect, maar de maatregelen kunnen wel helpen. Het nadeel van de "ik verzin bij een risico-acceptatie een maatregel die we volgens mij hebben en klets vervolgens naar een laag risico toe waarmee de kous af is" is dat je nooit afhankelijk moet zijn van 1 maatregel voor beveiliging van je assets. De kracht ligt in meerlaagse beveiliging (het hele principe achter defense-in-depth).

En nu het antwoord op je vraag: moeten we ons druk maken? Dat hangt er vanaf. Zijn de juiste maatregelen afgedwongen? Heeft het bedrijf een goed overzicht van haar assets en weet het wat waar draait? Detecteren we aanvallers die ons netwerk zijn binnengedrongen en misbruik maken van de zwakheid? Is de zwakheid uit te buiten via internet, of moet je 5 beveiligingslagen door voordat een aanvaller überhaupt in de buurt van de kwetsbare server? Mocht een bedreiging manifest worden, hoeveel data heeft het bedrijf dan van me? Heeft een aanvaller meteen alle data van me te pakken? Waar staat kortom mijn data binnen het bedrijf? En als mijn data buit is gemaakt, wat dan? Heb ik een probleem met identiteitsdiefstal als na 2 jaar misbruik van de data wordt gemaakt en de misbruikte gegevens niet te herleiden zijn tot de bank? Wat doet die bank dan?

Al die problemen en antwoorden zorgen ervoor dat een "one size fits all" risicobeoordeling niet bestaat. De vraag is simpelweg niet te beantwoorden zonder heel veel kennis van alle omgevingsfactoren.

Tot zover teveel tekst.

Apache is ook de naam van een webserver (software om websites te hosten). Deze webserver heeft niets te maken met de log4j-lekken waar je de laatste tijd over leest. Log4j is een loggingbibliotheek voor Java-software (software geschreven in de programmeertaal Java, niet te verwarren met Javascript). Apache-httpd (de webserver) is niet lek op dit moment.

Want klikken op " are you sure ?" En dan op " are you really sure? " Gaat niet zoiets worden als windows pop ups?

Vrij denigrerende opmerking als je het mij vraagt. De gebruiker alvast lekker in een hoek van de mislukkelingen schoppen. Dat gaat vast vruchten afwerpen. En die andere bewoording, dat gaat het verschil natuurlijk ook niet maken. Geef me 1 goede reden waarom een beheerder nu ineens voor "Abort" of "No" zou kiezen. Die is er niet.

Anderen verwijten zonder te vertellen wat ze dan fout hebben gedaan.
De eigen fouten bagatelliseren zonder duidelijk te zijn waarom de kwaliteit acceptabel zou zijn.
Vergeten te noemen dat er al jaren waarschuwing is om software hoe dan ook wantrouwig te maken.
Het ligt dus aan iedereen behalve aan Apache of de ontwikkelaars?

Die is er wel, dat people can run arbitrary code without authentication.

Hij schreeuwt wel vaker zonder ergens verstand van te hebben. Kijk maar zijn laatste bijdrage over een mailtje!

Dus maar allemaal overstappen op Nginx?

Het gaat hier over software die door bedrijven wordt ingezet, veelal op servers. Dan heb je het over professioneel gebruik waarbij je inderdaad expertise bij de gebruiker mag verwachten. De zorg die hij uitspreekt over hoe banken steeds meer hun beveiliging aan de laagste bieder uitbesteden gaat precies daarover: de benodigde expertise is aan het afkalven omdat men de laagste kosten najaagt.

De formulering "Ja, ik weet dat ik dom ben en ik weet het nog steeds zeker" vind ik heel ongelukkig gekozen, trouwens. "Ja, ik ben me ervan bewust dat dit een gevaarlijke instelling is maar ik weet wat ik doe" was beter geweest. Dat hij het niet al te letterlijk zo bedoeld kan hebben als hij het formuleerde wordt duidelijk als je bedenkt dat de configuratie van veel van die software, inclusief Log4j, helemaal niet via dialogen gaat waar je "ja" of "nee" aanvinkt, maar via configuratiebestanden die je met een teksteditor bewerkt, of dynamisch vanuit het computerprogramma dat de component gebruikt. Dan heb je het over waarschuwingen die in de documentatie van de configuratie-opties of de API-documentatie staan, en commentaar in eventuele voorbeeldconfiguratiebestanden en voorbeeld-broncode. Dat levert hoe dan ook andere formuleringen op dan deze, dus heel letterlijk zal hij het niet bedoeld hebben.

Als dat de enige reactie op het probleem was geweest had je een punt gehad, maar dat is niet zo. Ze hebben namelijk wel degelijk de melding opgepakt, gerepareerd, en dat aangepakt op een manier die erop gericht was de schade zo beperkt mogelijk te houden. Dat kan alleen niet zonder dat de gebruikers van de software ook direct in actie komen en die moeten dus ook in staat zijn om adequaat te reageren op een situatie. Het gaat hier om professioneel gebruik van software en dan mag je ook professionaliteit van de gebruiker ervan verwachten.

---

Een ander punt, als antwoord op jullie allebei, is dat dit open source software is die al die professionele gebruikers gratis kunnen gebruiken. De softwarelicentie geeft duidelijk aan, ze benadrukken het door het in hoofdletters op te schrijven, dat de software "as is" geleverd wordt, zonder enige garantie op geschiktheid voor wat voor doel dan ook.

Het is dus geen betaalde software. Je weet dat bij serieuze open source-projecten de makers wel degelijk gericht zijn op het repareren van fouten en beveiligingslekken, maar als je het gratis krijgt moet je niet verwachten dat je op hoge poten van een leverancier kan eisen dat die zich aan een contract houdt dat je helemaal niet met elkaar afgesloten hebt.

Je krijgt als gebruiker in plaats daarvan iets anders: de mogelijkheid om er zelf wat aan te doen. De broncode is beschikbaar, compleet met alle instellingen voor de tools die je nodig hebt om die te compileren. Als je als bedrijf zelf ontwikkelaars in dienst hebt kan je die erop zetten. Als je als bedrijf geld hebt kan je dat inzetten om het een ander te laten doen. Als je een fout weet te repareren kan je behalve een bugmelding te doen ook de reparatie aan het open source-project aanleveren.

Bedenk dat dat een van de fundamenten van het open source-model is: iedere gebruiker kan zijn steentje bijdragen, en door die bijdragen met iedereen te delen profiteert iedereen van de inspanning. Die inspanning hoeft dan niet door iedere afzonderlijke gebruiker van de software opnieuw gedaan te worden, één keer is genoeg. Per saldo krijgt iedere gebruiker, zelfs gebruikers die heel actief bijdragen leveren, veel meer gratis van al die anderen dan ze zelf weggeven. Laat dat even doordringen: open source is een geweldige kostenbesparing, zelfs als je er wél werk in steekt als gebruiker. En het vereist niet dat iedere gebruiker actief meedoet, het is al genoeg als dat maar door een deel van de gebruikers gedaan wordt.

Er zijn natuurlijk zat bedrijven die alleen maar kijken naar het minimaliseren van kosten en die zich als het erop aankomt heel arrogant gedragen alsof ze aanspraak kunnen maken op ondersteuning alsof ze daar wél een contract voor hebben afgesloten. Die hebben simpelweg hun huiswerk niet gedaan. Die letten niet op wat ze in huis halen en waar ze mee te maken kunnen krijgen. Als ze daarmee in de problemen komen is dat door hun eigen nalatigheid en hun eigen gebrek aan professionaliteit. Niemand is verplicht om open source-software te gebruiken, als het model je niet aanstaat kan je ook iets van bij een commerciële leverancier afnemen.

Het is overigens wel degelijk mogelijk om wél betaalde ondersteuning te krijgen op open source-software. Dat kan bijvoorbeeld door een betaalde licentie op een Linux-distributie voor professioneel gebruik te nemen. De garanties die een bedrijf daarmee koopt komen niet van de makers van de software, maar van bedrijven als RedHat die van het leveren van betaalde ondersteuning hun verdienmodel hebben gemaakt. Die zullen zo nodig bugs in software herstellen en de patch aan de eigenlijke makers van de software doorgeven.

Het komt er allemaal op neer dat je als professionele gebruiker van software tot je moet laten doordringen waar je eigenlijk mee te maken hebt en wat dat voor consequenties heeft. Nou zullen supercompetitieve types die alles als een zero sum game zien het open source-model domweg niet kunnen bevatten. Bij open source profiteert iedereen van wat iedereen weggeeft en krijgt iedereen die wat bijdraagt meer terug dan die zelf weggeeft. Dat is het absolute tegengestelde van een zero sum game, en het kan omdat software informatie is, uit bits en bytes bestaat, die nagenoeg gratis te kopiëren en verspreiden zijn. Maar het is niet het probleem van open source-ontwikkelaars dat er mensen zijn die zoiets niet kunnen bevatten, dat is het probleem en de eigen verantwoordelijkheid van degenen die dat niet kunnen.

Als het op jou allemaal zweverig en utopisch overkomt, en als je het feit niet overtuigend vindt dat er wel degelijk bedrijven bestaan die wél met succes op dit model inhaken en bijvoorbeeld ontwikkelcapaciteit beschikbaar stellen voor de open source-software die ze gebruiken, of ondersteuning ervoor verkopen, gebruik dan vooral geen open source-software.

Maar wat je als bedrijf ook doet: zorg dat je voldoende snapt wat je in huis haalt en wat dat voor consequenties heeft, en haal het niet in huis als je het niet snapt. En dat vergt dat je je huiswerk doet en kijkt waar je eigenlijk mee te maken hebt voor je het gaat gebruiken. Op basis daarvan is het terecht dat men bij Apache professionaliteit bij hun gebruikers verwacht.

Er zijn natuurlijk ook alternatieven voor Apache 2. Zo is er Hiawatha, dat is een webserver met security eigenschappen, ontwikkeld door een Nederlander en dat bestaat al heel lang. Er is ook Nginx, dat ook heel vaak gebruikt wordt. Maar OpenBSD gebruikt nog steeds Apache 1 en dat is dan ook nog serieus ingeperkt, met vele veiligheidsmaatregelen.

Omdat veel mensen gewoon slecht zijn in het begrijpend lezen van (nieuwe) meldingen, en anders niet de tijd nemen om de context van de vraagstelling te observeren.
Het doel is men attent te maken op de impact, dus maakt het niet uit wat je neerzet als het maar aanzet tot nadenken binnen die ene zin die wel gelezen wordt, waardoor er aangestuurd word om kennis op te doen omtrent de problematiek om zo de keuze bewust te maken.

Wat moet er dan staan?
'Yes do as I say!'? wat wel de nadruk geeft maar vrijwel gelijk staat aan gewoon 'yes' als je de rest niet hebt gelezen.
Of de waarschuwing wel hebt gelezen maar niet begrijpt en doorzet via een andere(geforceerde) methode die uiteindelijk de zelfde waarschuwing geeft, zoals in dit voorbeeld: https://yewtu.be/watch?v=0506yDSgU7M&t=10m10

Dat Hiawatha is GEEN APPLICATIESERVER dus niet geschikt om Java EE op te draaien. Dus houd op dat ding hier te spammen!

Hiawatha is een webserver en natuurlijk is het niet geschikt om rommel op te kunnen draaien. Ik dacht even dat wij het hier hebben op de site "security.nl", niet "app.nl".

We hebben het hier over professionele software die door grote bedrijven in grote professionele toepassingen wordt gebruikt (dat noem jij 'rommel') en niet over speelgoed dat een paar wereldvreemde hobbyisten heel wat vinden en waarmee ze bij gebrek aan belangstelling overal mee lopen te spammen.

Ik kwam onlangs een presentatie tegen in het kader van het Kernel Self Protection Project was ook hier bij past:
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf
De kern is dat we software niet alleen veilig moeten maken als het normaal draait, maar ook maatregelen moeten nemen dat het veilig blijft als het eens verkeerd gaat.

Maar die "professionele software" van jou heeft het wel mogelijk gemaakt om deze rommel te kunnen implementeren.

Persoonlijk hou ik veel meer van simpele dingen. Ik heb een hekel aan frameworks want al die abstracties zijn niet het antwoord. Je moet echt weten wat er gebeurd.

Dan verplaatst het zich gewoon.
De aanvallen zullen altijd tegen de grootste aandeelhouder gebeuren.

Goed voorbeeld daarin is de browser problemen uit het verleden.

Internet Explorer had vaak te kampen met vulnerabilities, dus nu is "iedereen" overgestapt op Chrome.
Nu heeft Chrom e de meeste vulnerabilities van alle browsers.
Als nu "iedereen" over zou stappen op Opera (om maar wat te noemen) ga je dat daar zien.

Een aanval op een kleine speler geeft weinig resultaat, als je nu stelt dat de Apache webserver vaak het haasje is komt dat niet omdat het een slecht product is maar omdat het vaak onderwerp is van onderzoek door kwaadwillenden omdat het aandeel aanzienlijk is in de markt.
Als gebruikers dus overstappen op Nginx zal dat het onderwerp worden.

Op dit moment is Internet Explorer de veiligste browser o te gebruiken, geen hond zoekt nog naar lekken omdat het aandeel in de markt nihil is.

Hoe kom je erbij dat het 'rommel' is?


Ja, zo had ik je ook al ingeschat.


Abstracties zijn altijd het antwoord bij softwareontwikkeling: “All problems in Computer Science can be solved by another level of indirection.” — Butler Lampson

Als ik dat zo lees is ie vooral zelf dom.
Het aanpassen van die instellingen gaat niet met een knopje waar je op moet klikken.
En het probleem bij log4j is niet de "domme mensen" die de instelling veranderd hebben, maar de "domme programmeurs" (of wellicht "domme distributeurs") die de instelling in de default configuratie verkeerd gezet hebben.
Je kunt niet verwachten dat iedere installatie van een softwarepakket door "een commerciële cybersecurity-expert" gedaan wordt, hoe graag je dat ook zo zou zien.
We hebben bij diverse pakketten al gezien dat het gewoon fout gaat als het niet default secure wordt uitgeleverd.
Zorg dan ook dat dat gebeurt, in plaats van de gebruiker de schuld te geven.

dat is je kop in het zand steken

Dat is de feiten ontkennen want hij heeft gewoon gelijk: Apache is een web/applicatie-server en log4j is een bibliotheek met logging functionaliteit. Die bibliotheek kan zowel op de server als in de client worden gebruikt en ik heb begrepen dat beide kwetsbaar zijn voor de in log4j gevonden vulnerability.

Alleen is het denk ik != i.p.v. =!

P.S. als je probeert te suggereren dat je met een hobbyisten web server als Hiawatha + PHP (?) software zou kunnen maken die qua complexiteit en robuustheid zelfs maar in de buurt komt van de Java EE software stack dan droom verder. Met name PHP is een gatenkaas vergeleken met Java en met alleen statische HTML kan je weinig meer maken dan sites die platte informatie uitdelen.

@ Toje Fos,

Ik ben het met je eens dat PHP rommel is, maar dat wordt ook heel vaak gebruikt door Apache en Nginx, dus wat is dan nog het verschil tussen die drie? Hiawatha is series en geen rommel. Maar Java is ook rommel, dat is wel gebleken.

"Top 10 Open Source Java and JavaEE Application Servers"
https://blog.idrsolutions.com/2015/04/top-10-open-source-java-and-javaee-application-servers/


Ha! Dat is een tik of spelfout hierboven (vet gemaakt). Als ik jouw redenatie zou volgen dan zou ik uit die ene fout concluderen dat jij 'rommel' bent. Voel je 'm? Je kan beter kijken naar hoe professioneel software is opgezet en waar het gebruikt wordt. Dan zie je dat Java / Java EE zeer professioneel opgezette software is en dat het in complexe toepassingen wordt gebruikt, waar robuustheid en veiligheid van groot belang zijn. Zoals bv. banken en andere financiële toepassingen; overheid, etc.

Wakkere. Dat was een typefout natuurlijk en moest natuurlijk Serieus zijn. De natuurlijk heb ik ook maar even aangedikt.

Nee, rommel! Waarom je dat natuurlijk vet heb gemaakt snap ik eigenlijk niet. Dat was toch goed gespeld?