Geen detectie, wel problemen: botsingen tussen Trellix en andere applicaties

Vorige keer heb ik jullie laten zien hoe je je system tree overzichtelijk kunt indelen. Daardoor kun je bijvoorbeeld upgrades gefaseerd uitrollen, policies testen of sneller conflicten vinden & oplossen. In deze editie van The Trellix Times kijken we naar dat laatste. Het kan namelijk best eens voorkomen dat Trellix en een ander stuk software elkaar bijten, met crashende applicaties tot gevolg. En dat wil natuurlijk niemand.

Het correct identificeren van conflicten tussen applicaties en specifieke onderdelen van Trellix ENS is cruciaal voor een snelle oplossing. Helaas is er geen pasklare indicatie dat Trellix de oorzaak is van een probleem met een applicatie. Maar we gaan je wel vertellen hoe je daarachter kunt komen. De eerste, meest eenvoudige stap die je kunt zetten, is om de website van de applicatie-ontwikkelaar te checken. Het kan namelijk voorkomen dat er bekende issues zijn tussen je applicatie en Trellix. In dat geval heeft de ontwikkelaar misschien al best practices of oplossingen op de website gezet. Dat kan je een hoop uitzoekwerk schelen. Is dat niet het geval? Dan moeten we zelf op onderzoek uit.

Hoe je de oorzaak vaststelt

Ken je de policy assignment rules nog? Die gaan we nu toepassen om uit te zoeken of, en zo ja welk onderdeel van, Trellix de oorzaak is van het probleem met je applicatie. Maak daarvoor eerst een aparte groep aan in je system tree, zodat je makkelijker onderzoek kunt doen door de policy assignment rules te testen. Trellix Endpoint Security bestaat uit meerdere modules, zoals ATP en Threat Prevention. We willen bepalen of één van deze modules misschien de reden is dat je applicatie crasht. Maak dus voor elke module een policy assignment rule aan die de module uitschakelt. Die kun je vervolgens één voor één toepassen op je test-groep om de verschillende modules uit te sluiten (of juist te bevestigen).

Heb je de module gevonden die je applicatie verstoort? Top! Maar dan zijn we er nog niet. Om namelijk je hele ATP uit te schakelen zodat één applicatie werkt, is vanuit security-perspectief natuurlijk niet wat je wilt. Gelukkig bestaat elke Trellix-module uit een heel aantal verschillende eigenschappen die je onafhankelijk kunt aan- of uitzetten. In het geval van ATP heb je bijvoorbeeld onder anderen de onderdelen Credential Theft Protection of Client-Based Scanning. Deze onderdelen onafhankelijk van elkaar testen, doe je ook met policy assignment rules op je test-groep. Je doet dus eigenlijk hetzelfde als in de vorige stap, maar kijkt nu een laag dieper.

Als je eenmaal hebt bepaald welke module en welk onderdeel van die module tot problemen leiden, kun je precies uitzoeken waar het mis gaat door gebruik te maken van de MER-tool (Minimal Escalation Requirements) van Trellix (als je deze tool nog niet kunt gebruiken vanuit je Trellix-producten, kun je ‘m downloaden via de Trellix support portal). Met deze tool kun je uitgebreide log-informatie verzamelen. Niet alleen van Trellix-producten zelf, maar ook van de meeste (OS-)processen waar ze op inhaken. Met de informatie uit MER kun je dus helemaal tot de kern komen van de storing. Heb je die kern eenmaal gevonden, dan heb je je aanknopingspunt om de issue op te lossen.

Verdere onderzoekstechnieken

Kom je er, na het analyseren van de output van de MER-tool, nog steeds niet uit? Dan moeten we nog een stapje verder en hebben we bijvoorbeeld misschien wel applicatie-logs nodig van de software die niet goed werkt. Dit lijkt me een mooi moment voor de reminder om vooral de knowledge bases van Trellix of de applicatie-ontwikkelaar te checken. Misschien is het een bekend probleem met een fix.

Niet? Dan moeten we dus echt dieper onderzoek uitvoeren. Dat doen we met de event logs van Windows, via de Windows Event Viewer. Die geeft je bredere informatie over wat er precies op je systeem gebeurt. In de Event Viewer kun je altijd terugkijken naar historische events en zoeken naar de juiste informatie van het tijdstip en moment waarop de crash plaatsvond. Toch maak je het jezelf een stuk makkelijk door het probleem nog eens te reproduceren. Dan heb je die informatie gelijk bij de hand, en hoef je jezelf niet scheel te zoeken tussen al die events.

Geven de verschillende logs en events je nog steeds niet genoeg info om je probleem te lokaliseren? Dan moeten we nog een stap verder en gaan we echt naar troubleshooting-niveau’tje “gevorderd”. Dat doen we met procmon, de Windows process monitor. Procmon vertelt je namelijk in real-time op een enorm gedetailleerd niveau wat er op een systeem gebeurt. Het zoeken van je oorzaak in een procmon kan een flinke klus zijn door de hoeveelheid informatie die de tool verzamelt. Maar als je ‘m eenmaal hebt gevonden, weet je wel dat je op het kleinst mogelijke niveau weet waarom je applicatie niet werkt, en of/hoe dat dan door een Trellix-functie kan komen.

Je issue oplossen

Nu je onderzocht hebt uit welk proces je issue komt, kun je deze vaak met een exclusion of policy-aanpassing oplossen. Het kan ook zo zijn dat je meer moet doen om de issue op te lossen. Dat hangt natuurlijk helemaal af van wat het probleem precies blijkt te zijn. Maar nu hoef je in ieder geval niet als een blinde vink door Trellix ENS of je systemen te gaan spitten en kun je gericht aan het werk.

Probleem nog niet kunnen vinden? Of wel gevonden, maar nog niet op kunnen lossen? Neem vooral contact op met mij of één van m’n collega’s en we helpen je verder..