Sophos ITDR Findings onderzoeken en beheren

Onder My Products > Identity > Findings toont Sophos ITDR de resultaten van controles op de gekoppelde identiteitsinfrastructuur. De tabel is standaard op risico gesorteerd. Een bevinding is niet automatisch het bewijs van een actieve compromittering en is evenmin een XDR Detection of een zelfstandige Case. ITDR kan risicovolle Findings samenbrengen in contextgerichte Cases; de afzonderlijke bevinding blijft echter een ITDR-werkitem dat moet worden beoordeeld, in het betreffende identiteitssysteem moet worden aangepakt en daarna opnieuw moet worden gecontroleerd.

De veilige workflow is:

1. Prioriteer open bevindingen op Risk en gebruik filters om een beheersbare werkwachtrij te creëren.
2. Lees Finding Details, Description, Definition en Recommendation; indien nodig, bekijk ruwe gegevens onder Result en wijzigingen onder History.
3. Beoordeel de impact en afhankelijkheden in uw eigen omgeving voordat u een configuratie wijzigt.
4. Verhelp de hoofdoorzaak in het getroffen identiteitssysteem of de betreffende dienst in plaats van alleen de ITDR-status te wijzigen.
5. Valideer de toestand eerst bij de provider en vervolgens in ITDR.
6. Zet een bevinding alleen na een bewuste beslissing op Resolved of Dismissed. De status handmatig wijzigen in Resolved is geen herstelmaatregel.

Statussen, risiconiveaus en categorieën correct interpreteren

Status

ITDR telt bevindingen met de status Resolved of Dismissed niet meer mee als risico voor de omgeving. Operationeel blijven de statussen echter verschillend: Resolved staat voor een verholpen oorzaak of verminderd risico, terwijl Dismissed staat voor een bewuste risicobeslissing.

Risico

Het risiconiveau is afkomstig van de onderliggende controle en helpt bij de prioritering. Onderzoek binnen hetzelfde niveau eerst blootgestelde geprivilegieerde identiteiten, aanwijzingen voor gecompromitteerde referenties en bevindingen met een grote impact. De specifieke Recommendation blijft belangrijker dan een algemene maatregel.

Categorie

ITDR gebruikt de volgende categorieën. De namen blijven ongewijzigd in de Engelse Sophos interface:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

De categorie beschrijft het type controle en kan waar toepasselijk aansluiten op het MITRE ATT&CK-model. De categorie vervangt geen gedetailleerde analyse of controle of een waargenomen configuratie in uw omgeving bewust zo is ingesteld.

Bevindingen filteren en een werkwachtrij maken

Het inklapbare filtermenu links van de tabel Identity Findings combineert de volgende filters:

• Risk: Risiconiveau van de bevinding.
• Status: Open, Resolved of Dismissed.
• Reference Type: type van het betrokken object.
• Category: categorie van de bevinding.
• Is New: bevindingen die in de afgelopen zeven dagen voor het eerst zijn waargenomen.
• Affected Provider: identiteitsprovider waarvoor de bevinding is gegenereerd; Microsoft Entra ID, On-premises Active Directory of All providers.
• Finding: titel van de bevinding.
• First Seen: tijdstip van de eerste waarneming.
• Last Seen: tijdstip van de laatste waarneming.
• Last Modified: tijdstip van de laatste wijziging.

Deze exacte waarden zijn beschikbaar voor Reference Type:

• User Object
• Application
• Group Object
• Device Object
• Agent Object
• Tenant Configuration
• Unknown

Agent Object beperkt de lijst tot agentgerelateerde bevindingen; dit geeft op zichzelf nog niet aan welke agentrol is getroffen. De Directory- en NHI-details onderscheiden runtime-identiteit, Blueprint Principal en een eventueel gekoppeld gebruikersaccount, evenals App Owners en Sponsors. Unknown geeft geen betrouwbare objectclassificatie; identificeer het concrete object via de details en Result. Affected Provider helpt de verantwoordelijke provider voor deze controle te selecteren. All providers is een filterkeuze, geen bewijs dat dezelfde bevinding bij beide providers bestaat.

Geselecteerde filters verschijnen boven de tabel. Gebruik X om één filter te verwijderen en Clear All om alle filters te verwijderen. De tabel en de URL worden dynamisch bijgewerkt op basis van de selectie. U kunt daarom een gefilterde URL als werkweergave opslaan of met collega’s delen. Controleer vóór het delen of de ontvangers toegang hebben tot dezelfde Sophos Fusion-tenant en of de URL in het beoogde ticket mag worden opgenomen.

Een nuttige eerste werkwachtrij gebruikt Status = Open, gevolgd door Risk = Critical of High. Verfijn de selectie vervolgens met Category, Reference Type of Is New. Zo blijven nieuwe kritieke identiteitsrisico’s zichtbaar zonder oudere openstaande items uit het oog te verliezen.

Onderzoek een bevinding grondig

Als u op de link in de kolom Findings klikt, wordt het detailpaneel geopend. Dit toont het bijbehorende object, het risico, First Seen, Last Seen, Last Modified en de aanbeveling. Gebruik het pictogram New Tab om de volledige pagina in een nieuw tabblad te openen.

Het paneel en volledige weergave omvatten:

• Finding Details: Samenvatting met risiconiveau, status, opmerkingen, tijdstempels en tags.
• Description: Beschrijving van de Bevinding.
• Definition: Informatie over de bijbehorende identiteitscontrole en de referenties ervan.
• Recommendation: aanbeveling van Sophos om het specifieke risico te verminderen.

Voor een betrouwbare triage moet u minstens de volgende vragen beantwoorden:

1. Welk object wordt beïnvloed en komt Reference Type overeen met het verwachte object?
2. Heeft de identiteitsprovider nog steeds de voorwaarde die beschreven is in Description en Definition?
3. Wat is de reikwijdte van de machtigingen en wat zijn de afhankelijkheden en mogelijke gevolgen van een wijziging?
4. Past de Recommendation bij uw omgeving en is de verandering intern toegestaan?
5. Geven First Seen, Last Seen en Last Modified een nieuw, terugkerend of reeds behandeld probleem aan?

Finding Details toont opmerkingen en tags. De Sophos-documentatie voor de pagina Findings beschrijft echter geen toewijzingsfunctie en ook geen bedieningselementen om opmerkingen of tags te maken of te wijzigen. Leg verantwoordelijkheden en bewijs van wijzigingen daarom vast in het goedgekeurde wijzigings- of ticketsysteem; opmerkingen vervangen noch een wijzigingsticket, noch bewijs van de wijziging in het bronsysteem.

Result als ruwe gegevens beoordelen

Het tabblad Result toont de ruwe uitvoer van de uitgevoerde controle in JSON-formaat. Het is vooral nuttig wanneer uit de samenvatting niet blijkt welk kenmerk, object of resultaat tot de beoordeling heeft geleid.

Behandel JSON-sleutels en -waarden als de uitvoer van de specifieke controle; leid er geen algemeen schema uit af. Vergelijk relevante object-ID’s, toestanden en tijdstempels met de actuele informatie bij de identiteitsprovider. Gevoelige ruwe gegevens horen alleen thuis in goedgekeurde tickets of onderzoeksnotities.

Wijzigingen volgen via de geschiedenis

Het tabblad History toont eerdere acties voor de bevinding. Met View Diff opent u de exacte wijzigingen. Daar kunt u statuswijzigingen en andere verwerkingsstappen volgen, zodat u onderscheid kunt maken tussen een onverwachte heropening en een nieuwe bevinding.

Remedieer de oorzaak en bevestig de uitkomst

⚠️ Controleren voordat u wijzigingen aanbrengt: Een aanbeveling van Sophos moet passen bij uw omgeving, risicotolerantie en wijzigingsgoedkeuring. Wijzigingen in rollen, authenticatie, voorwaardelijke toegang, toepassingen of andere identiteitsobjecten kunnen gevolgen hebben voor gebruikers, toepassingen en toegang. Breng daarom vóór de implementatie de afhankelijkheden en het terugvalplan in kaart.

Remediatie vindt plaats in het systeem waar ITDR het probleem heeft gedetecteerd, zoals de verbonden identiteitsprovider of de verantwoordelijke applicatieservice. De status in ITDR regelt alleen de Findings workflow. Het verandert de configuratie van de provider niet.

Een gecontroleerde sluiting bestaat uit vier stappen:

1. Controleer de status bij de provider: Bevestig dat de goedgekeurde wijziging is opgeslagen en van kracht is voor het getroffen object.
2. Controleer de bevinding opnieuw: Bekijk het bijbehorende object, Last Seen, Result en History. Een verouderd of ongewijzigd resultaat is geen bewijs van succes.
3. Wacht op de automatische verwerking: Als de bevinding bij een nieuwe controle niet meer verschijnt, lost ITDR deze automatisch op en voegt het een opmerking toe. De Entra ID-houdingscontroles en controles op slapende resources worden doorgaans om de twee uur uitgevoerd; de organisatiebrede Risk Posture Score wordt dagelijks bijgewerkt.
4. Documenteer het resultaat: Leg bewijs van de provider, de status van de bevinding, het tijdstip en, indien van toepassing, View Diff vast in het goedgekeurde werkdocument. Blijft de bevinding na een verwacht controle-interval open, vergelijk dan opnieuw de providerstatus, het getroffen object en het JSON-resultaat in plaats van de status herhaaldelijk handmatig te wijzigen.

Een bevinding die handmatig op Resolved is gezet, kan door het systeem weer op Open worden gezet zodra ITDR dezelfde toestand opnieuw waarneemt. Dit is geen fout in het statusmodel, maar een aanwijzing dat de oorzaak nog bestaat, opnieuw is opgetreden of nog zichtbaar is in de gegevens die ITDR beoordeelt.

Gebruik Dismissed alleen als bewuste risicobeslissing

⚠️ Dismissed onderdrukt verdere bevindingen: Als een bevinding wordt afgewezen, maakt ITDR voor dit probleem op het getroffen object geen nieuwe bevindingen aan. De bevinding blijft in de tabel staan, maar wordt uitgesloten van het dashboard en de organisatiebrede Risk Posture Score. Door een bevinding te vroeg af te wijzen, kan een bestaand of later opnieuw relevant risico aan het normale zicht worden onttrokken.

Dismissed is alleen geschikt wanneer de toestand wordt verwacht, herstel aantoonbaar onmogelijk of operationeel niet te rechtvaardigen is en de verantwoordelijke partij het restrisico aanvaardt. Documenteer buiten ITDR ten minste het object, de reden, compenserende maatregelen, de goedkeuring en de herbeoordelingsdatum. Een technisch onoplosbare bevinding kan ook Open blijven, zodat het risico zichtbaar blijft in de score en de doorlopende bewaking.

Credential Compromise prioriteren

Bevindingen voor gecompromitteerde accounts worden alleen voor actieve identiteiten gegenereerd. ITDR controleert onder meer of er een actieve identiteit bestaat, wanneer een wachtwoord in platte tekst of een hash voor het eerst is uitgelekt en of die datum na de laatste wachtwoordwijziging ligt. Een waarde in platte tekst wordt bovendien getoetst aan de algemene eisen voor wachtwoordcomplexiteit van Microsoft Entra ID. De ruwe gegevens kunnen onder Dark Web Intelligence zichtbaar blijven, ongeacht of er een bevinding wordt gegenereerd.

Wanneer een bevinding wordt gegenereerd, bepaalt ITDR het risiconiveau aan de hand van het accounttype, het type lek en de sterkte van MFA:

Behandel voor de prioritering eerst Critical en daarna High; onderzoek binnen hetzelfde niveau eerst geprivilegieerde accounts en lekken van wachtwoorden in platte tekst. Een lagere classificatie bij ingeschakelde of phishingbestendige MFA betekent niet dat de bevinding kan worden genegeerd. Voer goedgekeurde beschermende en corrigerende maatregelen uit in het verantwoordelijke identiteitssysteem en volgens uw incidentresponsproces. Valideer vervolgens de toestand bij de provider, de bevinding en de geschiedenis zoals hierboven beschreven. De status alleen bevestigt niet dat een identiteit veilig is.

Verantwoordelijkheden van klant, MDR en XDR scheiden

Sophos ITDR is een door de klant bewaakte oplossing. Ook met een afzonderlijk gelicentieerde Sophos MDR-service blijven de routinematige triage en het beheer van bevindingen de verantwoordelijkheid van de klant. Het MDR Operations Team richt zich op actieve identiteitsbedreigingen en kan afzonderlijke kritieke bevindingen of bevindingen met een hoog risico in zijn onderzoek opnemen als deze op een actieve bedreiging wijzen. Dit betekent niet dat alle bevindingen automatisch worden overgenomen of dat wijzigingen bij de identiteitsprovider worden uitgevoerd.

Voor elke geëscaleerde bevinding moet daarom duidelijk worden vastgelegd:

• wie verantwoordelijk is voor triage- en risicobeslissingen,
• wie wijzigingen in het identiteitssysteem goedkeurt en uitvoert;
• of een indicatie van een actieve bedreiging is doorgegeven aan het overeengekomen MDR-proces;
• wie het technische effect en de ITDR-status definitief valideert.

ITDR-bevindingen blijven afzonderlijke werkitems, gescheiden van XDR Detections en de overkoepelende Case. Identiteitscontext en samengevoegde Findings kunnen verder onderzoek ondersteunen. De status, opmerkingen en afsluiting van de afzonderlijke ITDR-bevinding zijn echter niet gelijk aan de XDR-, Case- of MDR-workflow.

Cases en directe respons correct interpreteren

Sophos beschrijft het automatisch samenbrengen van risicovolle Findings in contextgerichte Cases. Daar worden voor het onderzoek verbanden gelegd tussen identiteiten, Detections en andere risicofactoren. Een Case vormt een aanvulling op de afzonderlijke bevindingen; hij vervangt noch de controle van Result en History, noch het bewijs dat een oorzaak is verholpen. Uit de aankondiging worden hier geen vaste groeperingsdrempels, menupaden voor Cases, overname van statussen of automatische accountingrepen afgeleid.

Tot de directe responsmogelijkheden vanuit ITDR behoren wachtwoordresets en het intrekken van actieve sessies. Sophos noemt daarnaast het afdwingen van MFA en het uitschakelen van accounts. Deze mogelijkheden zijn geen algemene garantie voor elke provider of elk objecttype: de technische respons moet voor de concrete omgeving zijn ingericht. De actuele responsdocumentatie beschrijft daarvoor verbindingen, Actions en playbooks, bij Entra ID bijvoorbeeld via de Microsoft Graph API Connector. Alleen de ITDR-gegevensintegratie of een alleen-lezen AD-sensor verleent nog geen schrijfrechten voor respons.

Documenteer voor een goedgekeurde reactie de Finding-ID en eventuele Case-ID, de betrokken identiteit, de uitgangssituatie, het tijdstip en het resultaat. Controleer daarna eerst bij de provider of de beoogde wijziging effectief is en controleer vervolgens dezelfde bevinding in ITDR. Alleen een wachtwoordreset bewijst niet dat sessies zijn ingetrokken; een gesloten Case bewijst geen technisch herstel. Herhaal mislukte of onduidelijke acties niet blind, maar escaleer ze met het waargenomen resultaat naar het verantwoordelijke identiteitsbeheerteam.

Als later geautomatiseerde respons wordt ingericht, moet de trigger afzonderlijk worden gecontroleerd: de actuele documentatie beveelt voor nieuw aangemaakte Identity Findings Created aan. Updated kan bij terugkerende Posture Checks meerdere keren per dag afgaan en daardoor bijvoorbeeld herhaaldelijk wachtwoorden resetten. Het automatisch groeperen van Cases is op zichzelf geen opdracht om dergelijke responsautomatisering in te schakelen.