Trellix Tactics: botsingen tussen Trellix en andere applicaties

Soms werkt een applicatie ineens niet meer goed. Geen foutmelding of log. Alleen enorme vertraging of zelfs crashes. Dan komt vaak de vraag: ligt dit aan onze security-configuratie? En dat is zeker niet ondenkbaar. Gelukkig kun je dat systematisch uitzoeken en oplossen, zonder meteen je hele bescherming plat te leggen en je omgeving kwetsbaar achter te laten. 

We helpen klanten dagelijks met dit soort issues. Dus weten we niet alleen hoe je het oplost, maar vooral ook waarom het werkt. En dat vertellen we je allemaal in deze editie van Trellix Tactics. 

UPDATE 3 juni 2025: dit is een nieuwe, ingekorte versie van een ouder blog. Het onderstaande artikel is oorspronkelijk gepubliceerd als nieuwsbrief op onze LinkedIn-pagina. Wil je als eerste op de hoogte zijn van onze Trellix Tactics? Abonneer je hier op de LinkedIn-nieuwsbrief.

Stap voor stap onderzoek doen 

1. Check eerst of het probleem al bekend is 

De kortste route naar een oplossing: de website van de leverancier van je applicatie. Als daar al staat dat Trellix met die software kan botsen, dan ben je snel klaar. Vaak vind je daar ook best practices voor exclusions of configuraties, die je direct kunt toepassen. 

2. Gebruik policy assignment rules om stapsgewijs uit te sluiten 

Je wilt weten of een specifieke module van Trellix, zoals ATP of Threat Prevention, de crash veroorzaakt. Overigens merken we in de praktijk dat dit soort issues vaak wordt veroorzaakt door de On-Access Scan, dus onze tip: begin daar.  

Door een testgroep aan te maken in je system tree, en met policies modules één voor één uit te schakelen, sluit je gerichte onderdelen uit. Zo ontdek je stap voor stap welke module het probleem veroorzaakt. Zonder risico voor je productieomgeving. Zorg er hierbij voor dat je rekening houdt met het communicatie-interval tussen ePO en het endpoint. Je kunt dit interval ook forceren, zodat de nieuwe policy direct naar het endpoint wordt gepusht. 

3. Ga een laag dieper binnen de module 

Heb je de verantwoordelijke module gevonden? Dan stop je daar niet. Trellix-modules bestaan uit losse onderdelen die je onafhankelijk kunt aan- of uitzetten. ATP bevat bijvoorbeeld ‘Credential Theft Protection’ en ‘Client-Based Scanning’. Door deze onderdelen afzonderlijk te testen met nieuwe rules, zoom je verder in op de oorzaak. Zo houd je fijnmazige controle over je troubleshoot-proces. 

4. Gebruik de SSSO-tool voor diepgaande loganalyse 

De Self-Service Supportability Orchestrator-tool van Trellix (wat eerst WebMER heette) is je forensische vergrootglas. Deze tool verzamelt logdata van zowel Trellix als onderliggende OS-processen. Daarmee kun je onderzoeken welke proces precies botst met welk beveiligingsonderdeel. Je komt in deze stap dus verder tot de kern van de issue. 

5. Event Viewer en Procmon: voor als je nóg verder moet graven 

Soms kom je er met policies en SSSO alleen niet uit. Dan is Windows Event Viewer je volgende stap: die laat zien wat er op systeemniveau gebeurde rond de crash. Of je reproduceert de crash en gebruikt de Process Monitor (procmon), een tool die real-time alles logt wat je systeem doet. Daarmee achterhaal je zelfs de meest hardnekkige conflictsituaties. 

6. Tijd voor de fix 

Weet je welk onderdeel het probleem veroorzaakt? Dan kun je het meestal oplossen met een exclusion of een policy-aanpassing. En omdat je weet waarom die fix nodig is, weet je ook precies wat de impact is op je security. Zo voorkom je dat je te veel uitschakelt. 

Tot slot 

Dit soort problemen oplossen draait niet alleen om techniek. Het draait om begrijpen wat je tools doen, hoe ze je systeemperformance en security kunnen beïnvloeden, en hoe je die invloed beheerst. En dat is precies waar we onze klanten bij helpen. Dus kom je er met de bovenstaande stappen nog niet lekker uit? Bel of stuur een bericht, we denken graag met je mee.