Att tänka på när du integrerar säkerhetstjänster som inte kommer från Microsoft med Microsoft 365

Microsoft tillhandahåller en omfattande plattform för e-postsäkerhet, men vi förstår att vissa kunder använder en djupskyddsstrategi för e-postsäkerhet genom att lägga till en säkerhetstjänst från tredje part (icke-Microsoft). Det finns två saker att tänka på när du implementerar säkerhetstjänster som inte kommer från Microsoft med Microsoft 365:

• Om icke-Microsoft-tjänsten ökar organisationens säkerhetsstatus och kompromisserna för att göra det. Till exempel:

  • Mer kostnad.
  • Mer komplexitet.
  • Antalet falska positiva identifieringar (bra objekt markerade som dåliga) ökar när fler produkter läggs till.
  • Så integrerar säkerhetstjänsten från slutpunkt till slutpunkt. Till exempel:
    • Icke-Microsoft-tjänsten bör ge en användarupplevelse som inte kräver att användarna funderar på vilken karantän som ska användas.
    • Icke-Microsoft-tjänsten bör integreras med befintliga säkerhetsåtgärder (SecOps) processer och verktyg. Till exempel säkerhetsinformation och händelsehantering (SIEM), säkerhetsorkestrering, automatisering och svar (SOAR) osv.

  Obs!

  Email säkerhet är ett kontradiktoriskt utrymme. Med ökningen av vanliga nätfiske- och attackkit utvecklas och omvandlas attacker snabbt. Det är därför Microsoft Defender för Office 365 är en del av Microsoft Defender XDR, vår strategi med flera lager, före intrång och efter intrång för företagets cybersäkerhet.

  Oavsett hur många lager av e-postskydd som finns når det totala skyddet aldrig 100 procent.

• Hur icke-Microsoft-tjänsten söker igenom och agerar på e-postmeddelanden. Vanligtvis föreslår säkerhetstjänster som inte kommer från Microsoft följande tre integreringsalternativ, och alla dessa alternativ stöds inte lika mycket av Microsoft just nu.

Integrering via DNS-e-postroutning (MX-post pekar på icke-Microsoft-tjänsten)

Den här konfigurationen beskrivs i detalj i Utökad filtrering för anslutningsappar i Exchange Online och stöds fullt ut av Microsoft. Email säkerhetsleverantörer som stöder autentiserad mottagen kedja (ARC) fungerar bäst, men det finns begränsningar. Undvik till exempel att använda säkra länkar för att kontrollera och omsluta länkar med en tjänst som inte kommer från Microsoft och som även skriver om länkar. Dubbellänkshantering kan förhindra att säkra länkar validerar länkstatus, detonerar länkar för hot och potentiellt utlöser engångslänkar. Vi rekommenderar att du inaktiverar funktionen för länkomslutning i tjänsten som inte kommer från Microsoft.

Mer information om den här konfigurationen finns i Hantera e-postflöde med hjälp av en molntjänst från tredje part med Exchange Online.

Integrering via Microsoft Graph API

Vissa tjänster som inte kommer från Microsoft autentiserar och använder Microsoft-Graph API för att skanna meddelanden när de har levererats till användarpostlådor. Med den här konfigurationen kan även icke-Microsoft-tjänsten ta bort meddelanden som de anser vara skadliga eller oönskade. Normalt kräver den här konfigurationen fullständig åtkomst till postlådor av tjänsten som inte kommer från Microsoft. Se till att du förstår säkerhets- och supportrutinerna för tjänsten som inte kommer från Microsoft innan du beviljar den här behörigheten.

Integrering via in-och-ut-e-postroutning

Med den här konfigurationen kan MX-posten peka på Microsoft 365. Icke-Microsoft-tjänsten fungerar dock efter e-postskydd och bearbetning i Microsoft 365 enligt följande diagram:

Den här konfigurationen kräver att meddelandet lämnar microsoft 365-tjänstgränsen. När meddelandet returneras från icke-Microsoft-tjänsten behandlas det som ett helt nytt meddelande av Microsoft 365. Det här beteendet resulterar i följande problem och komplexitet:

• Meddelanden räknas två gånger i de flesta rapporteringsverktyg, inklusive Explorer (Threat Explorer), Avancerad jakt och automatiserad undersökning och svar (AIR). Det här beteendet gör det svårt att korrekt korrelera meddelandeutfallet och åtgärderna.

• Eftersom meddelanden som kommer tillbaka till Microsoft 365 sannolikt misslyckas med e-postautentiseringskontroller kan meddelandena identifieras som förfalskning (falska positiva identifieringar). Vissa tjänster som inte kommer från Microsoft rekommenderar att du använder e-postflödesregler (transportregler) eller IP-anslutningsfiltrering för att lösa problemet, men det kan leda till att falska negativa identifieringar levereras.

• Kanske viktigast av allt är att maskininlärning i Defender för Office 365 inte fungerar så effektivt som möjligt. Maskininlärningsalgoritmer förlitar sig på korrekta data för att fatta beslut om innehåll. Inkonsekventa eller ändrade data kan påverka inlärningsprocessen negativt, vilket leder till en minskning av den övergripande effektiviteten hos Defender för Office 365. Exempel inkluderar:

  • Rykte: Med tiden identifierar maskininlärningsmodellerna de element som är associerade med bra och dåligt innehåll (IP-adresser, skickande domäner, URL:er osv.). När meddelanden returneras från icke-Microsoft-tjänsten bevaras inte de första sändande IP-adresserna och kan minska effektiviteten hos IP-adresser för att ge en korrekt bedömning. Det här beteendet kan också påverka inlämningar, som diskuteras i punkt 3 senare.
  • Ändringar av meddelandeinnehåll: Många e-postsäkerhetstjänster lägger till meddelandehuvuden, lägger till ansvarsfriskrivningar, ändrar innehållet i meddelandetexten och/eller skriver om URL:er i meddelanden. Även om det här beteendet vanligtvis inte är ett problem kan levererade meddelanden som innehåller dessa ändringar som senare bedöms vara skadliga och tas bort via automatisk rensning utan timme (ZAP) lära maskininlärning att dessa ändringar indikerar ett felaktigt meddelande.

Av dessa skäl rekommenderar vi starkt att du undviker den här konfigurationen och arbetar med tjänstleverantören som inte kommer från Microsoft för att använda de andra integreringsalternativen som beskrivs i den här artikeln. Men om du måste använda den här konfigurationen rekommenderar vi starkt följande inställningar och åtgärder för att maximera din skyddsstatus:

1. Konfigurera Defender för Office 365 principåtgärder för att placera alla negativa omdömen i karantän. Även om den här konfigurationen kan vara mindre användarvänlig än att använda mappen Skräppost Email sker skräpåtgärden endast vid slutlig leverans till postlådan. Ett e-postmeddelande som skulle ha levererats till mappen Junk Email skickas i stället till tjänsten som inte kommer från Microsoft. Om/när det här meddelandet kommer tillbaka till Microsoft finns det ingen garanti för att den ursprungliga domen (till exempel skräppost) bevaras. Det här beteendet leder till lägre övergripande effektivitet.

   Tips

   E-postflödesregler (transportregler) som tittar på ursprungliga domar är inte idealiska, eftersom de kan introducera andra problem och leda till effektivitetsutmaningar.

2. Minimera falska positiva identifieringar genom att åsidosätta förfalskning för e-post som kommer från tjänsten som inte kommer från Microsoft. Om till exempel icke-Microsoft-tjänsten har en IP-adress på 172.17.17.35 skapar du två tillåtna falska avsändarposter i listan Tillåt/blockera för klientorganisation: en extern och en Intern enligt följande skärmbild:

   

   Se till att ta bort dessa åsidosättningsposter om du lämnar skyddstjänsten som inte kommer från Microsoft eller ändrar hur den fungerar.

3. Falska negativa (felaktig e-post tillåts) och falska positiva e-postöverföringar till Microsoft bör komma från den ursprungliga versionen av meddelandet, inte den som returneras från tjänsten som inte kommer från Microsoft. Falska positiva identifieringar som tillskrivs icke-Microsoft-tjänsten ska skickas till tjänsten som inte kommer från Microsoft. Det här kravet kan vara komplicerat att hantera:

   • Microsofts falska negativa (missade vid den första mottagningen): Du behöver en kopia av meddelandet innan du kan leverera till postlådan. Skicka kopian i karantän från icke-Microsoft-tjänsten, om den är tillgänglig.
   • Microsoft + icke-Microsoft-tjänsten falskt negativt: Om båda tjänsterna missar det rekommenderar vi att du rapporterar det ursprungliga objektet till Microsoft och rapporterar objektet i mottagarens postlåda till tjänsten som inte kommer från Microsoft. Objektet som returneras till Microsoft 365 från icke-Microsoft-tjänsten innehåller information från icke-Microsoft-tjänsten (till exempel att tjänsten som inte kommer från Microsoft skickar IP-adresser, anpassade huvuden osv.) som kan leda till minskad maskininlärningseffektivitet.
   • Microsofts falska positiva identifiering: Om meddelandet ursprungligen fångades av Microsoft före utvärdering av icke-Microsoft-tjänsten gäller det att skicka den här kopian från karantänen.
   • Falsk positiv identifiering från icke-Microsoft-tjänsten: Om icke-Microsoft-tjänsten fångade meddelandet måste du skicka meddelandet till dem eftersom Microsoft inte kan åtgärda problemet.

Integrera meddelanderapporteringsverktyg som inte kommer från Microsoft

Defender för Office 365 har användarrapporterade inställningar som fungerar med den inbyggda rapportknappen i versioner av Outlook som stöds, eller tillägg för Microsoft-rapportmeddelande eller rapportfiske.

Med vetskapen om att säkerhetstjänster som inte kommer från Microsoft kan innehålla egna verktyg och processer för rapportering av falska positiva identifieringar och falska negativa identifieringar (inklusive utbildnings-/medvetenhetsinsatser för användare) stöder Defender för Office 365 inlämningar från rapporteringsverktyg från tredje part. Det här stödet hjälper dig att effektivisera rapporteringen av falska positiva och falska negativa identifieringar till Microsoft, och ger ditt SecOps-team möjlighet att dra nytta av Microsoft Defender XDR incidenthantering och automatiserade undersökningar och svar (AIR).

Mer information finns i Alternativ för rapporteringsverktyg från tredje part.