Probleem met Microsoft Defender for Cloud: Ingebouwde Qualys-scanner detecteert Log4j niet

Question

Hallo team,

We proberen te controleren of de ingebouwde Qualys-scanner in Microsoft Defender for Cloud de Log4j-kwetsbaarheid in onze Azure-omgeving detecteert, maar zonder succes.

We hebben alles correct ingeschakeld in ons testabonnement en bevestigd dat de agent is geconfigureerd en draait op de Windows Server waarop SQL Server wordt gehost. Maar na meer dan 48 uur wachten toont Defender nog steeds niets. Beveiligingsrapporten zijn erg belangrijk voor ons, dus eerlijk gezegd is dit behoorlijk frustrerend.

Voor de zekerheid heb ik de Qualys Log4j-scantool lokaal handmatig uitgevoerd en deze detecteerde onmiddellijk het kwetsbare bestand log4j-1.2.17.jar. Ik begrijp dus niet waarom Defender dit niet signaleert.

Zijn er beperkingen, vertragingen of misconfiguraties die dit gedrag kunnen veroorzaken?

Answer 1

Hallo EstteLauder,

De ingebouwde Qualys-scanner in Microsoft Defender for Cloud is op 1 mei 2024 officieel met pensioen gegaan (deprecated) en uitgefaseerd. Als je deze integratie nu nog probeert te gebruiken, kijk je naar een dode functionaliteit die geen definities meer bijwerkt.

Maar zelfs toen de scanner nog actief was, is het volkomen logisch dat hij log4j-1.2.17.jar miste. Hier is de architectonische reden: De geïntegreerde Qualys-agent in Defender keek standaard alleen naar het OS-register en de geïnstalleerde pakketten. Hij voerde geen "deep filesystem scanning" uit (het doorzoeken en uitpakken van losse .jar-bestanden op de C-schijf), omdat dit de I/O van de server compleet zou platleggen. Het standalone Qualys-script dat je lokaal draaide, forceerde wél een agressieve scan over de hele schijf.

Vergeet Qualys in de cloud portal. Je moet de Vulnerability Assessment provider in je Defender for Servers plan onmiddellijk omzetten naar Microsoft Defender Vulnerability Management (MDVM).

MDVM is de officiële, native vervanger van Microsoft. Het gebruikt de Defender for Endpoint-sensor om naadloos en zonder zware performance-impact op bestandsniveau te scannen naar Log4j-kwetsbaarheden.

Tracy Le.