Så här undersöker du risker

Microsoft Entra ID Protection innehåller flera riskrapporter som kan användas för att undersöka identitetsrisker i din miljö. Undersökning av händelser är nyckeln till bättre förståelse och identifiering av eventuella svaga punkter i din säkerhetsstrategi. ID Protection-rapporter kan arkiveras för lagring eller integreras med SIEM-verktyg (Security Information and Event Management) för vidare analys. Organisationer kan också dra nytta av Microsoft Defender-, Microsoft Sentinel- och Microsoft Graph API-integreringar för att aggregera data med andra källor.

Det finns många sätt att undersöka risker i din miljö och ännu mer information att tänka på under undersökningen. Den här artikeln innehåller ett ramverk som hjälper dig att komma igång och beskriver några av de vanligaste scenarierna och rekommenderade åtgärderna.

Förutsättningar

Inledande sortering

När du påbörjar den initiala triagen rekommenderar vi följande åtgärder:

  1. Granska instrumentpanelen för ID Protection för att visualisera antalet attacker, antalet högriskanvändare och andra viktiga mått baserat på identifieringar i din miljö.

  2. Granska riskrapporterna för att undersöka information om eventuella nya riskfyllda användare, inloggningar eller identifieringar.

  3. Granska arbetsboken Konsekvensanalys för att förstå scenarier där risker är uppenbara i din miljö och vilka riskbaserade åtkomstprinciper som ska aktiveras för att hantera högriskanvändare och inloggningar.

  4. Granska inloggningsloggarna för att identifiera liknande aktiviteter med samma egenskaper. Den här aktiviteten kan vara en indikation på mer komprometterade konton.

    1. Om det finns vanliga egenskaper, till exempel IP-adress, geografi, framgång/fel osv., kan du överväga att blockera dem med en princip för villkorsstyrd åtkomst.
    2. Granska vilka resurser som kan komma att komprometteras, inklusive potentiella datanedladdningar eller administrativa ändringar.
    3. Aktivera självreparationsprinciper via villkorsstyrd åtkomst.

  5. Med Insider Risk Management via Microsoft Purview kan du kontrollera om användaren utförde andra riskfyllda aktiviteter, till exempel att ladda ned en stor mängd filer från en ny plats. Det här beteendet är en stark indikation på en möjlig kompromiss.

Om du misstänker att en angripare kan personifiera användaren bör du kräva att användaren återställer sitt lösenord och utför MFA eller blockerar användaren och återkallar alla uppdaterings- och åtkomsttoken.

Ramverk för undersökning och riskreparation

Organisationer kan använda följande ramverk för att undersöka misstänkt aktivitet. När risken identifieras är det rekommenderade första steget självreparation, om det är ett alternativ. Självreparation kan ske via självbetjäning av lösenordsåterställning eller genom reparationsflöde för en riskbaserad princip för villkorsstyrd åtkomst.

Om självreparation inte är ett alternativ måste en administratör åtgärda risken. Reparationen utförs genom att anropa en lösenordsåterställning, kräva att användaren registrerar om för MFA, blockerar användaren eller återkallar användarsessioner. Följande flödesdiagram visar det rekommenderade flödet när en risk har identifierats:

Diagram som visar riskreparationsflödet.

När risken är innesluten kan det krävas mer undersökning för att markera risken som säker, komprometterad eller för att avvisa den.

  1. Kontrollera inloggningsloggarna och kontrollera om aktiviteten är normal för den angivna användaren.

    1. Titta på användarens tidigare aktiviteter, inklusive följande egenskaper, för att se om de är normala för den angivna användaren.
      • Program – används appen ofta av användaren?
      • Enhet – Är enheten registrerad eller kompatibel?
      • Plats – reser användaren till en annan plats eller får åtkomst till enheter från flera platser?
      • IP-adress
      • Användaragentsträng

  2. Undersök med andra säkerhetsverktyg, där det är tillgängligt.

    • Om du har Microsoft Sentinel kontrollerar du om det finns motsvarande aviseringar som kan tyda på ett större problem.
    • Om du har Microsoft Defender XDR kan du följa en användarriskhändelse genom andra relaterade aviseringar och incidenter.
    • MITRE ATT&CK-kedjan via Microsoft Sentinel i Microsoft Defender XDR kan också ge insikter. I Microsoft Defender-portalen bläddrar du till Incidenter och aviseringar>Aviseringar> och anger produktnamnsfiltret till AAD Identity Protection för att hitta aviseringar från Microsoft Entra ID Protection.

  3. Kontakta användaren för att bekräfta om de känner igen inloggningen. Tänk dock på att e-post eller Teams kan komma att komprometteras.

    1. Bekräfta den information som du har, till exempel:
      • Tidsstämpel
      • Applikation
      • Enhet
      • Plats
      • IP-adress

  4. Beroende på resultatet av undersökningen markerar du användaren eller inloggningen som bekräftad komprometterad, bekräftad säker eller avfärdar risken.

  5. Konfigurera riskbaserade principer för villkorsstyrd åtkomst för att förhindra liknande attacker eller åtgärda eventuella luckor i täckningen.

Undersöka specifika upptäckter

Vissa riskidentifieringar kräver specifika undersökningssteg. I följande avsnitt beskrivs några av de vanligaste riskidentifieringarna och rekommenderade åtgärder.

Microsoft Entra-hotintelligens

Om du vill undersöka en Microsoft Entra-hotinformationsriskidentifiering följer du dessa steg baserat på informationen i fältet "ytterligare information" i fönstret Information om riskidentifiering:

  • Om inloggningen kom från en misstänkt IP-adress:

    1. Kontrollera om IP-adressen visar misstänkt beteende i din miljö.
    2. Genererar IP-adressen ett stort antal fel för en användare eller uppsättning användare i din katalog?
    3. Kommer ip-trafiken från ett oväntat protokoll eller program, till exempel äldre Exchange-protokoll?
    4. Om IP-adressen motsvarar en molntjänstleverantör utesluter du att det inte finns några legitima företagsprogram som körs från samma IP-adress.

  • Kontot utsattes för en lösenordssprayattack

    1. Kontrollera att inga andra användare i katalogen är mål för samma attack.
    2. Kontrollera om andra användare har inloggningar med liknande atypiska mönster som visas i den identifierade inloggningen inom samma tidsram. Lösenordssprayattacker kan visa ovanliga mönster i:
      • Användaragentsträng
      • Applikation
      • Protokoll
      • Intervall med IP-adresser/ASN:er
      • Tid och frekvens för inloggningar

  • Identifiering utlöstes av en realtidsregel

    1. Kontrollera att inga andra användare i katalogen är mål för samma attack. Den här informationen finns med hjälp av det TI_RI_#####-nummer som tilldelats regeln.
    2. Realtidsregler skyddar mot nya attacker som identifieras av Microsofts forskning om hotinformation. Om flera användare i katalogen var mål för samma attack undersöker du ovanliga mönster i andra attribut för inloggningen.

Atypiska resedetekteringar

  • Om du bekräftar att aktiviteten inte utfördes av en legitim användare:
    1. Markera inloggningen som komprometterad och anropa en lösenordsåterställning om den inte redan utförs av självreparation.
    2. Blockera användaren om angriparen har åtkomst till att återställa lösenord eller utföra MFA och återställa lösenord.
  • Om en användare är känd för att använda IP-adressen inom ramen för sina uppgifter bekräftar du inloggningen som säker.
  • Om du bekräftar att användaren nyligen har rest till det mål som anges i aviseringen bekräftar du inloggningen som säker.
  • Om du bekräftar att IP-adressintervallet kommer från ett sanktionerat VPN bekräftar du inloggningen som säker och lägger till VPN IP-adressintervallet till namngivna platser i Microsoft Entra ID och Microsoft Defender för Cloud Apps.

Avvikande token- och utgivaranomalidetektioner

  • Om du bekräftar att aktiviteten inte utfördes av en legitim användare med hjälp av en kombination av riskvarning, plats, program, IP-adress, användaragent eller andra egenskaper som är oväntade för användaren:

    1. Markera inloggningen som komprometterad och anropa en lösenordsåterställning om den inte redan utförs av självreparation.
    2. Blockera användaren om en angripare har åtkomst till att återställa lösenord eller utföra.
    3. Konfigurera riskbaserade principer för villkorsstyrd åtkomst för att kräva lösenordsåterställning, utföra MFA eller blockera åtkomst för alla högriskinloggningar.

  • Om du bekräftar att plats, program, IP-adress, användaragent eller andra egenskaper förväntas för användaren och det inte finns andra tecken på kompromisser kan du låta användaren självreparera med en riskbaserad princip för villkorsstyrd åtkomst eller låta en administratör bekräfta inloggningen som säker.

För ytterligare undersökning av tokenbaserade identifieringar, se blogginlägget Token taktik: Hur man förhindrar, upptäcker och reagerar på stöld av molntoken och Handbok för utredning av tokenstöld.

Misstänkta webbläsaridentifieringar

Den här identifieringen anger att användaren inte ofta använder webbläsaren eller att aktiviteten i webbläsaren inte matchar användarens normala beteende.

  • Bekräfta inloggningen som komprometterad och anropa en lösenordsåterställning om den inte redan utförs av självreparation. Blockera användaren om en angripare har åtkomst till att återställa lösenord eller utföra MFA.
  • Konfigurera riskbaserade principer för villkorsstyrd åtkomst för att kräva lösenordsåterställning, utföra MFA eller blockera åtkomst för alla högriskinloggningar.

Identifiering av skadliga IP-adresser

  • Om du bekräftar att aktiviteten inte utfördes av en legitim användare:

    1. Bekräfta inloggningen som komprometterad och anropa en lösenordsåterställning om den inte redan utförs av självreparation.
    2. Blockera användaren om en angripare har åtkomst till att återställa lösenord eller utföra MFA och återställa lösenord och återkalla alla token.
    3. Konfigurera riskbaserade principer för villkorsstyrd åtkomst för att kräva lösenordsåterställning eller utföra MFA för alla högriskinloggningar.

  • Om du bekräftar att användaren använder IP-adressen inom ramen för sina uppgifter bekräftar du inloggningen som säker.

Detektering av lösenordssprayer

En identifiering av lösenordsspray innebär att Microsoft observerade en angripare som utförde en sprayattack och uppnådde en lyckad validering av autentiseringsuppgifter mot en användare i din klientorganisation. Sprayattacken kan ha riktats mot användare i många klienter – upptäckten sker endast i klienter där en lyckad lösenordsmatchning har bekräftats. Misslyckade sprayförsök genererar ingen identifiering.

  • Om du bekräftar att aktiviteten inte utfördes av en legitim användare:

    1. Markera inloggningen som komprometterad och anropa en lösenordsåterställning om den inte redan utförs av självreparation.
    2. Blockera användaren om en angripare har åtkomst till att återställa lösenord eller utföra MFA och återställa lösenord och återkalla alla token.

  • Om du bekräftar att användaren använder IP-adressen inom ramen för sina uppgifter bekräftar du inloggningen som säker.

  • Om du bekräftar att kontot inte har komprometterats och inte ser några indikatorer för "brute force"-attack eller lösenordsspray mot kontot:

    1. Tillåt användaren att självreparera med en riskbaserad princip för villkorsstyrd åtkomst eller låta en administratör bekräfta inloggningen som säker.
    2. Se till att microsoft Entra smart lockout har konfigurerats på rätt sätt för att undvika onödiga kontoutelåsningar.

För ytterligare undersökning av detektering av lösenordssprayrisker, se artikeln Lösenordssprayundersökning.

Identifiering av läckta autentiseringsuppgifter

Identifiering av läckta autentiseringsuppgifter är alltid hög risk eftersom de representerar exponering av bekräftade autentiseringsuppgifter. När den här identifieringen utlöses ska du undersöka det omedelbart.

Om den här identifieringen identifierade en läckt autentiseringsuppgift för en användare:

  1. Utvärdera exponeringens omfattning. Granska användarens riskhistorik och inloggningsloggar för att avgöra om den läckta autentiseringsuppgiften användes för obehörig åtkomst. Leta efter korrelerade inloggningsriskhändelser som inloggningar från okända platser, anonyma IP-adresser eller atypiska resor.
  2. Kontrollera om lösenordet redan har ändrats. Kontrollera om användaren har ändrat sitt lösenord efter det datum då läckan upptäcktes. En molnbaserad lösenordsåterställning som utlöses av en princip för villkorsstyrd åtkomst i Microsoft Entra åtgärdar helt användarrisken för den här identifieringen. Om lösenordet har ändrats kan risken redan vara självåtgärdad. Annars bekräftar du att användaren har komprometterats och initierar en lösenordsåterställning.
  3. Blockera åtkomst om en angripare är aktiv. Om inloggningsloggar visar obehörig åtkomst eller om en angripare har möjlighet att återställa lösenordet eller utföra MFA blockerar du användaren, återställer lösenordet och återkallar alla uppdateringstoken. Det är viktigt att återkalla sessioner när det finns bevis för en aktiv kompromiss.
  4. Granska för lateral förflyttning. Kontrollera användarens senaste aktivitet för tecken på eskalering av privilegier, nya appregistreringar, ändringar av postlåderegler eller åtkomst till känsliga resurser som kan tyda på aktivitet efter kompromissen.
  5. Verifiera anslutna konton. Om användaren återanvänder lösenord mellan tjänster bör du överväga att autentiseringsuppgifterna har komprometterats utanför din klientorganisation. Be användaren att ändra lösenord för andra tjänster där de använder samma autentiseringsuppgifter.

Minimera framtida risker

  • Lägg till företagets VPN och IP-adressintervall till namngivna platser i dina principer för villkorsstyrd åtkomst för att minska falska positiva identifieringar.
  • Överväg att skapa en databas för kända resenärer för den uppdaterade organisationens reserapportering och använda den för att korsreferera reseaktivitet.
  • Ge feedback i ID Protection för att förbättra identifieringsprecisionen och minska falska positiva identifieringar.

Nästa steg

  • Last updated on