Del via

Viktige faktorer for å integrere ikke-Microsoft-sikkerhetstjenester med Microsoft 365

Microsoft tilbyr en omfattende plattform for e-postsikkerhet, men vi forstår at enkelte kunder tar i bruk en detaljert forsvarsstrategi for e-postsikkerhet ved å legge til en tredjeparts sikkerhetstjeneste (ikke Microsoft). Det er to vurderinger for å innlemme ikke-Microsoft-sikkerhetstjenester med Microsoft 365:

  • Om ikke-Microsoft-tjenesten øker organisasjonens sikkerhetsstilling og avveiningene for å gjøre det. Eksempel:

    • Mer kostnad.
    • Mer kompleksitet.
    • Frekvensen av falske positiver (gode elementer merket som dårlige) øker etter hvert som flere produkter legges til.
    • Hvordan ikke-Microsoft-sikkerhetstjenesten integrerer ende-til-ende. Eksempel:
      • Ikke-Microsoft-tjenesten bør gi en brukeropplevelse som ikke krever at brukerne tenker på hvilken karantene som skal brukes.
      • Tjenesten som ikke er Fra Microsoft, bør integreres med eksisterende sikkerhetsoperasjoner (SecOps)-prosesser og -verktøy. For eksempel sikkerhetsinformasjon og hendelsesbehandling (SIEM), orkestrering av sikkerhet, automatisering og respons (SOAR) osv.

    Obs!

    E-postsikkerhet er et motsatt rom. Med fremveksten av varephishing- og angrepspakker utvikler angrep seg og transformeres raskt. Det er derfor Microsoft Defender for Office 365 er en del av Microsoft Defender XDR, vår flerlags, pre-brudd og post-brudd tilnærming til enterprise cyber sikkerhet.

    Uansett hvor mange lag med e-postbeskyttelse som finnes, når total beskyttelse aldri 100 prosent.

  • Hvordan ikke-Microsoft-tjenesten skanner og fungerer på e-postmeldinger. Vanligvis foreslår ikke-Microsoft-sikkerhetstjenester følgende tre integreringsalternativer, og ikke alle disse alternativene er like støttende for Microsoft på dette tidspunktet.

Integrering via DNS-e-postruting (MX-post peker til ikke-Microsoft-tjenesten)

Denne konfigurasjonen dekkes i detalj i utvidet filtrering for koblinger i Exchange Online og støttes fullstendig av Microsoft. Leverandører av e-postsikkerhet som støtter Arc (Authenticated Received Chain), fungerer best, men det finnes begrensninger. Du kan for eksempel unngå å bruke klarerte koblinger til å kontrollere og bryte koblinger med en ikke-Microsoft-tjeneste som også omskriver koblinger. Dobbel koblingsbryting kan hindre klarerte koblinger i å validere koblingsstatus, detonere koblinger for trusler og potensielt utløse engangsbrukskoblinger. Vi anbefaler at du deaktiverer funksjonen for koblingsbryting i ikke-Microsoft-tjenesten.

Hvis du vil ha mer bakgrunn om denne konfigurasjonen, kan du se Administrere e-postflyt ved hjelp av en tredjeparts skytjeneste med Exchange Online.

Integrering via Microsoft Graph-API-en

Noen ikke-Microsoft-tjenester godkjenner og bruker Microsoft Graph-API-en til å skanne meldinger etter at de er levert til brukerpostbokser. Denne konfigurasjonen gjør det også mulig for ikke-Microsoft-tjenesten å fjerne meldinger som de mener er skadelige eller uønskede. Denne konfigurasjonen krever vanligvis full tilgang til postbokser fra ikke-Microsoft-tjenesten. Pass på å forstå sikkerhets- og støttepraksisen for ikke-Microsoft-tjenesten før du gir denne tillatelsen.

Integrering via inn-og-ut-e-postruting

Med denne konfigurasjonen kan MX-posten peke til Microsoft 365. Ikke-Microsoft-tjenesten fungerer imidlertid etter e-postbeskyttelse og -behandling for Microsoft 365, som vist i diagrammet nedenfor:

diagram som viser e-postflyt med en ikke-Microsoft-sikkerhetstjeneste som brukes etter e-postlevering til Microsoft 365.

Tips

Forbedret filtrering for koblinger fungerer ikke med denne konfigurasjonen. Forbedret filtrering for koblinger er utformet for scenarioer der ikke-Microsoft-tjenesten er før Microsoft 365, som tidligere forklart i inndelingen Integrering via DNS-e-postruting . Tjenesten som ikke er fra Microsoft før Microsoft 365, gjør at den fullstendige stakken for e-postbeskyttelse kan fungere, samtidig som den intelligent forhindrer falske positiver relatert til infrastrukturen som ikke er sendt fra Microsoft-tjenesten. Du kan ikke bruke utvidet filtrering for koblinger til å klarere alle meldinger fra Microsoft 365 IP-adresser.

Denne konfigurasjonen krever at meldingen forlater tjenestegrensen for Microsoft 365. Når meldingen kommer tilbake fra ikke-Microsoft-tjenesten, behandles den som en helt ny melding fra Microsoft 365. Denne virkemåten resulterer i følgende problemer og kompleksiteter:

  • Meldinger telles to ganger i de fleste rapporteringsverktøyene, inkludert Explorer (Trusselutforsker), Avansert jakt og automatisert undersøkelse og respons (AIR). Denne virkemåten gjør det vanskelig å koordinere meldingsdommen og handlingene på riktig måte.

  • Fordi meldinger som kommer tilbake til Microsoft 365 sannsynligvis mislykkes med godkjenningskontroller av e-post, kan meldingene identifiseres som forfalskning (falske positiver). Noen ikke-Microsoft-tjenester anbefaler at du bruker regler for e-postflyt (transportregler) eller IP-tilkoblingsfiltrering for å løse dette problemet, men det kan føre til at falske negativer blir levert.

  • Kanskje viktigst av alt, maskinlæring i Defender for Office 365 fungerer ikke så effektivt som mulig. Maskinlæringsalgoritmer er avhengige av nøyaktige data for å ta beslutninger om innhold. Inkonsekvente eller endrede data kan påvirke læringsprosessen negativt, noe som fører til en reduksjon i den generelle effektiviteten til Defender for Office 365. Eksempler inkluderer:

    • Omdømme: Over tid oppdager maskinlæringsmodellene elementene som er knyttet til godt og dårlig innhold (IP-adresser, sending av domener, nettadresser osv.). Når meldinger kommer tilbake fra ikke-Microsoft-tjenesten, bevares ikke IP-adressene for første gang, og de kan redusere effektiviteten til IP-adresser ved å gjengi en riktig dom. Denne virkemåten kan også påvirke innsendinger, som beskrives i punkt 3 senere.
    • Endringer i meldingsinnhold: Mange sikkerhetstjenester for e-post legger til meldingshoder, legger til ansvarsfraskrivelser, endrer innholdet i meldingsteksten og/eller skriver om nettadresser i meldinger. Selv om dette vanligvis ikke er et problem, kan leverte meldinger som inneholder disse endringene som senere er fastslått å være skadelige og fjernet via nulltimers automatisk tømming (ZAP), lære maskinlæring om at disse endringene indikerer en dårlig melding.

Av disse grunnene anbefaler vi på det sterkeste å unngå denne konfigurasjonen og arbeide med leverandøren av ikke-Microsoft-tjenesten for å bruke de andre integreringsalternativene som er beskrevet i denne artikkelen. Hvis du imidlertid må ta i bruk denne konfigurasjonen, anbefaler vi på det sterkeste følgende innstillinger og operasjoner for å maksimere beskyttelsesstillingen:

  1. Konfigurer Defender for Office 365 policyhandlinger for å sette alle negative vurderinger i karantene. Selv om denne konfigurasjonen kan være mindre brukervennlig enn å bruke Søppelpost-mappen, skjer søppelposthandlingen bare ved endelig levering til postboksen. En e-postmelding som ville blitt levert til Søppelpost-mappen, sendes i stedet til tjenesten som ikke er fra Microsoft. Hvis/når denne meldingen kommer tilbake til Microsoft, er det ingen garanti for at den opprinnelige dommen (for eksempel søppelpost) bevares. Denne virkemåten fører til lavere generell effektivitet.

    Tips

    Regler for e-postflyt (transportregler) som ser på opprinnelige dommer, er ikke ideelle, fordi de kan introdusere andre problemer og føre til effektivitetsutfordringer.

  2. Minimer falske positiver ved å overstyre forfalskning for e-post som kommer fra ikke-Microsoft-tjenesten. Hvis ikke-Microsoft-tjenesten har en IP-adresse på 172.17.17.35, kan du for eksempel opprette to tillatte falske avsenderoppføringer i leierens tillatelses-/blokkeringsliste: én ekstern og én intern som vist i følgende skjermbilde:

    Et skjermbilde av tillatte falske avsenderoppføringer i leierens tillatelses-/blokkeringsliste.

    Pass på å fjerne disse overstyringsoppføringene hvis du forlater beskyttelsestjenesten som ikke er Fra Microsoft, eller endre hvordan den fungerer.

  3. Usann negativ (ugyldig e-post er tillatt) og falske positive e-postinnsendinger til Microsoft skal komme fra den opprinnelige versjonen av meldingen, ikke den som returnerer fra ikke-Microsoft-tjenesten. Falske positiver som er tilskrevet ikke-Microsoft-tjenesten, skal sendes til ikke-Microsoft-tjenesten. Dette kravet kan være komplisert å administrere:

    • Microsoft false negative (tapt ved første mottak): Du trenger en kopi av meldingen før du kan levere til postboksen. Send inn kopien i karantene fra ikke-Microsoft-tjenesten hvis den er tilgjengelig.
    • Usann negativ for Microsoft + ikke-Microsoft-tjeneste: Hvis begge tjenestene går glipp av det, anbefaler vi at du rapporterer det opprinnelige elementet til Microsoft og rapporterer elementet i mottakerens postboks til ikke-Microsoft-tjenesten. Elementet som returneres til Microsoft 365 fra ikke-Microsoft-tjenesten, inneholder detaljer fra ikke-Microsoft-tjenesten (for eksempel ikke-Microsoft-tjenestens sending av IP-adresser, egendefinerte overskrifter osv.), noe som kan føre til redusert effektivitet for maskinlæring.
    • Microsoft false positive: Hvis meldingen først ble fanget opp av Microsoft før evaluering av ikke-Microsoft-tjenesten, er det effektivt å sende inn denne kopien fra karantene.
    • Ikke-Microsoft-tjenesten er positiv: Hvis ikke-Microsoft-tjenesten fanget meldingen, må du sende meldingen til dem, fordi Microsoft ikke kan løse problemet.

Integrere meldingsrapporteringsverktøy som ikke er fra Microsoft

Defender for Office 365 har brukerrapportinnstillinger som fungerer med den innebygde rapportknappen i støttede versjoner av Outlook, eller tilleggene Microsoft Report Message eller Report Phishing.

Hvis du vet at ikke-Microsoft-sikkerhetstjenester kan omfatte egne verktøy og prosesser for rapportering av falske positiver og falske negativer (inkludert innsats for brukeropplæring/bevissthet), støtter Defender for Office 365 innsendinger fra tredjeparts rapporteringsverktøy. Denne støtten bidrar til å effektivisere rapportering av falske positiver og falske negativer til Microsoft, og gir SecOps-teamet mulighet til å dra nytte av Microsoft Defender XDR hendelsesbehandling og automatiserte undersøkelser og respons (AIR).

Hvis du vil ha mer informasjon, kan du se Alternativer for tredjeparts rapporteringsverktøy.