Veelvoorkomende fouten bij het gebruik van endpoint detection en response (EDR)

 

We hebben veel gevallen gezien waarin producten voor endpoint detection en response (EDR) niet de bescherming bieden die een klant van hen verwachtte. Er waren verschillende redenen waarom dit het geval was, maar de meeste gevallen hebben iets gemeen: de klant gebruikte het product niet op de juiste manier. Omdat het altijd nuttig is om te leren van fouten van anderen, zal deze blogpost veelvoorkomende fouten beschrijven die we hebben gezien.

 

Functies en regelsets niet inschakelen

EDR-producten worden geleverd met een groot aantal functies en regelsets die mogelijk niet zijn ingeschakeld binnen uw organisatie. Een reden hiervoor kan zijn dat de betreffende functies standaard zijn uitgeschakeld en nooit zijn ingeschakeld. Een andere reden kan zijn dat deze functies veel false positives hebben gegenereerd en met opzet zijn uitgeschakeld. In elk geval zal het niet gebruiken van de functies en regelsets van uw EDR-product resulteren in lagere detectie- en preventiepercentages. Hoe u met false positives moet omgaan, wordt verderop besproken. Het startpunt van een configuratietraject moet echter zijn: de tijd nemen om de functies van uw product te begrijpen, of ze zijn ingeschakeld en of ze dat zouden moeten zijn.

 

Volledige regelsets uitvoeren in detectiemodus

Een tweede oplossing voor het false positive probleem dat we zijn tegengekomen, is het uitvoeren van volledige regelsets in de zogenaamde detectiemodus. In deze modus worden processen niet beëindigd voor het activeren van detectieregels. In plaats daarvan worden waarschuwingen gegenereerd zodat menselijke analisten ernaar kunnen kijken en actie kunnen ondernemen. Hoewel de detectiemodus een handige functie is, zoals we later zullen zien, zou het niet de oplossing moeten zijn voor het false positive probleem. Analisten worden overspoeld met waarschuwingen en hebben geen tijd om ze goed te analyseren. Omdat nieuwe waarschuwingen in hetzelfde tempo blijven binnenkomen, worden ze gesloten met weinig inspectie.

 

Geen fine grained uitzonderingen gebruiken

In een grote omgeving zullen EDR-producten false positives genereren. Dit kan een reden zijn geweest om bewust functies en regelsets binnen uw organisatie uit te schakelen, of om regelsets in detectiemodus uit te voeren. Hoewel dit ervoor zorgt dat uw gebruikers hun taken kunnen uitvoeren, vermindert het ook de effectiviteit van uw EDR-product. Wat u wilt doen, is fine grained uitzonderingen implementeren op individuele regels die false positives veroorzaken. Onderzoek de false positives en probeer er een patroon in te ontdekken dat:
A. Uniek is aan de false positives
B. Waarschijnlijk niet gekopieerd is door een aanvaller

Detecties die niet aan het patroon voldoen, moeten leiden tot beëindiging van het proces. Uitzonderingen maken die false positives minimaliseren en tegelijkertijd false negatives voorkomen, vereist expertise in het opsporen van bedreigingen en/of aanvalssimulatie.

Uitzonderingen maken die false positives minimaliseren en tegelijkertijd false negatives voorkomen, valt buiten de scope van deze blogpost. Het is er echter deels in opgenomen om te benadrukken dat aanvallers zullen proberen hun acties er zo legitiem mogelijk uit te laten zien. Op het meest basale niveau voeren ze hun kwaadaardige code uit in de context van legitieme processen, het is niet voldoende om gedrag van bekende processen op de whitelist te zetten. Wanneer de casus te complex is om automatisch classificatie uit te voeren, kan de detectiemodus worden gebruikt om te voorkomen dat gebruikers hun werk niet kunnen doen.

 

De oplossing niet testen

In veel gevallen bestaat er een discrepantie tussen wat organisaties denken dat hun oplossing zal doen en wat het daadwerkelijk doet. Terwijl false positives leiden tot klachten van gebruikers, blijven false negatives onopgemerkt in het dagelijks gebruik. Het testen van uw EDR-product en de configuratie ervan is essentieel om inzicht te krijgen in de doeltreffendheid ervan, om op de hoogte te zijn van eventuele gaps en om weloverwogen beslissingen te nemen over aanvullende vereiste beveiligingsmaatregelen. Test tegen een groot aantal offensieve tools, evenals individuele technieken die gericht zijn op het omzeilen van EDR-oplossingen. Verder dienen periodiek tests te worden uitgevoerd met een geactualiseerde set van tools en technieken, om te bepalen in hoeverre de oplossing bijblijft bij de snelle ontwikkelingen van de offensieve kant.

 

Conclusie

Wanneer u een EDR-oplossing goed afstemt op uw omgeving, kunt u gebruikmaken van veel meer van de functies ervan zonder de ervaring van eindgebruikers te beperken. Dit zorgt voor een bredere dekking van mogelijke aanvallen die u kunt detecteren. Bovendien voorkom je dat je SOC-analisten overspoeld worden met false positives, waardoor ze meer tijd hebben om complexere detectiegebeurtenissen te onderzoeken. Ongeacht de configuratie die u uiteindelijk gebruikt is het belangrijk om de oplossing met realistische scenario’s te testen, zodat u weet waartoe deze in staat is en, nog belangrijker, wat niet.