Overfør til Microsoft Defender for Office 365 – fase 3: Ombord


Fase 1: Forbered deg.
Fase 1: Forbered		 Fase 2: Konfigurer.
Fase 2: Konfigurere		 Fase 3: Ombord.
Fase 3: Ombord
Du er her!

Velkommen til fase 3: Om bord ioverføringen til Microsoft Defender for Office 365! Denne overføringsfasen inkluderer følgende trinn:

  1. Start pålasting av sikkerhetsteam
  2. (Valgfritt) Fritatt pilotbrukere fra filtrering av den eksisterende beskyttelsestjenesten
  3. Juster forfalskningsintelligens
  4. Justere representasjonsbeskyttelse og postboksintelligens
  5. Bruke data fra brukerrapporterte meldinger til å måle og justere
  6. (Valgfritt) Legge til flere brukere i prøveprosjektet og gjenta
  7. Utvid Microsoft 365-beskyttelsen til alle brukere, og deaktiver SCL=-1-regelen for e-postflyt
  8. Bytt MX-postene

Trinn 1: Start pålasting av sikkerhetsteam

Hvis organisasjonen har et sikkerhetsresponsteam, er det nå på tide å begynne å integrere Microsoft Defender for Office 365 i svarprosessene dine, inkludert billettsystemer. Denne prosessen er et helt emne for seg selv, men blir noen ganger oversett. Å få sikkerhetsresponsteamet involvert tidlig sikrer at organisasjonen er klar til å håndtere trusler når du bytter MX-poster. Hendelsesresponsen må være godt rustet til å håndtere følgende oppgaver:

Hvis organisasjonen kjøpte Microsoft Defender for Office 365 Plan 2, bør de begynne å gjøre seg kjent med og bruke funksjoner som Trusselutforsker, Avansert jakt og Hendelser. Hvis du vil ha relevante opplæringer, kan du se https://aka.ms/mdoninja.

Hvis sikkerhetsresponsteamet samler inn og analyserer ufiltrerte meldinger, kan du konfigurere en SecOps-postboks til å motta disse ufiltrerte meldingene. Hvis du vil ha instruksjoner, kan du se Konfigurere SecOps-postbokser i den avanserte leveringspolicyen.

SIEM/SOAR

Hvis du vil ha mer informasjon om integrering med SIEM/SOAR, kan du se følgende artikler:

Hvis organisasjonen ikke har et sikkerhetsresponsteam eller eksisterende prosessflyter, kan du bruke denne tiden til å gjøre deg kjent med grunnleggende jakt- og responsfunksjoner i Defender for Office 365. Hvis du vil ha mer informasjon, kan du se Trusselundersøkelse og -respons.

RBAC-roller

Tillatelser i Defender for Office 365 er basert på rollebasert tilgangskontroll (RBAC) og forklares i Tillatelser i Microsoft Defender-portalen. Her er de viktige punktene å huske på:

  • Microsoft Entra roller gir tillatelser til alle arbeidsbelastninger i Microsoft 365. Hvis du for eksempel legger til en bruker i sikkerhetsadministratoren i Azure Portal, har de sikkerhetsadministratortillatelser overalt.
  • E-post & samarbeidsroller i Microsoft Defender portalen gir tillatelser til Microsoft Defender-portalen og Microsoft Purview-samsvarsportal. Hvis du for eksempel legger til en bruker i sikkerhetsadministratoren i Microsoft Defender-portalen, har de bare tilgang til sikkerhetsadministrator i Microsoft Defender-portalen og Microsoft Purview-samsvarsportal.
  • Mange funksjoner i Microsoft Defender-portalen er basert på Exchange Online PowerShell-cmdleter og krever derfor rollegruppemedlemskap i tilsvarende roller (teknisk sett rollegrupper) i Exchange Online (spesielt for tilgang til tilsvarende Exchange Online PowerShell cmdleter).
  • Det finnes e-& samarbeidsroller i Microsoft Defender-portalen som ikke tilsvarer Microsoft Entra roller, og som er viktige for sikkerhetsoperasjoner (for eksempel rollen Forhåndsvisning og rollen Søk og Tøm).

Vanligvis trenger bare et delsett av sikkerhetspersonell flere rettigheter til å laste ned meldinger direkte fra brukerpostbokser. Dette behovet krever en ekstra tillatelse som sikkerhetsleseren ikke har som standard.

Trinn 2: (Valgfritt) Fritatt pilotbrukere fra filtrering av eksisterende beskyttelsestjeneste

Selv om dette trinnet ikke er nødvendig, bør du vurdere å konfigurere pilotbrukerne til å omgå filtrering av den eksisterende beskyttelsestjenesten. Denne handlingen gjør det mulig for Defender for Office 365 å håndtere alle filtrerings- og beskyttelsesoppgaver for pilotbrukerne. Hvis du ikke fritar pilotbrukerne fra den eksisterende beskyttelsestjenesten, fungerer Defender for Office 365 effektivt bare på feil fra den andre tjenesten (filtrering av meldinger som allerede er filtrert).

Obs!

Dette trinnet er eksplisitt nødvendig hvis den gjeldende beskyttelsestjenesten tilbyr koblingsbryting, men du vil prøve ut sikker koblingsfunksjonalitet. Dobbel tekstbryting av koblinger støttes ikke.

Trinn 3: Justere forfalskningsintelligens

Kontroller forfalskingsintelligensinnsikten for å se hva som tillates eller blokkeres som forfalsking, og for å finne ut om du må overstyre systemdommen for forfalskning. Noen kilder til den forretningskritiske e-posten kan ha feilkonfigurerte poster for e-postgodkjenning i DNS (SPF, DKIM og DMARC), og du bruker kanskje overstyringer i den eksisterende beskyttelsestjenesten til å maskere domeneproblemene.

Forfalskningsintelligens kan redde e-post fra domener uten riktige poster for e-postgodkjenning i DNS, men funksjonen trenger noen ganger hjelp til å skille god forfalskning fra dårlig forfalskning. Fokuser på følgende typer meldingskilder:

  • Meldingskilder som er utenfor IP-adresseområder som er definert i utvidet filtrering for koblinger.
  • Meldingskilder som har flest meldinger.
  • Meldingskilder som har størst innvirkning på organisasjonen.

Forfalskningsintelligens vil etter hvert justere seg selv etter at du har konfigurert brukerrapporterte innstillinger, slik at det ikke er behov for perfeksjon.

Trinn 4: Justere representasjonsbeskyttelse og postboksintelligens

Når du har hatt nok tid til å observere resultatene av representasjonsbeskyttelse i Ikke bruk noen handlingsmodus , kan du enkeltvis slå på hver representasjonsbeskyttelseshandling i policyene for anti-phishing:

  • Beskyttelse mot brukerrepresentasjon: Sett meldingen i karantene både for standard og streng.
  • Beskyttelse mot domenerepresentasjon: Sett meldingen i karantene for både Standard og Strict.
  • Beskyttelse mot postboksintelligens: Flytt meldingen til mottakernes søppelpostmapper for Standard. Sett meldingen i karantene for Strict.

Jo lenger du overvåker resultatene av representasjonsbeskyttelsen uten å handle på meldingene, jo mer data må du identifisere tillater eller blokker som kan være nødvendige. Vurder å bruke en forsinkelse mellom å slå på hver beskyttelse som er betydelig nok til å tillate observasjon og justering.

Obs!

Hyppig og kontinuerlig overvåking og justering av disse beskyttelsene er viktig. Hvis du mistenker en falsk positiv, må du undersøke årsaken og bruke overstyringer bare etter behov og bare for gjenkjenningsfunksjonen som krever det.

Justere postboksintelligens

Selv om postboksintelligens er konfigurert til ikke å gjøre noe på meldinger som var fast bestemt på å være etterligningsforsøk, er det aktivert og lært at e-posten sender og mottar mønstre fra pilotbrukerne. Hvis en ekstern bruker er i kontakt med en pilotbruker, identifiseres ikke meldinger fra den eksterne brukeren som etterligningsforsøk av postboksintelligens (noe som reduserer falske positiver).

Når du er klar, gjør du følgende for å tillate postboksintelligens å handle på meldinger som oppdages som representasjonsforsøk:

  • I anti-phishing-policyen med standard beskyttelsesinnstillinger endrer du verdien for Hvis postboksintelligens oppdager at en representert brukerflytter meldingen til mottakernes søppelpostmapper.

  • I policyen for anti-phishing med innstillingene for streng beskyttelse, endrer du verdien for Hvis postboksintelligens oppdager og utga seg for å være bruker fra til karantene meldingen.

Hvis du vil endre policyene, kan du se Konfigurere policyer for anti-phishing i Defender for Office 365.

Når du har observert resultatene og gjort eventuelle justeringer, går du videre til neste del for å sette meldinger i karantene som oppdages av brukerrepresentasjon.

Justere beskyttelse for brukerrepresentasjon

I begge policyene for anti-phishing basert på standardinnstillinger og strenge innstillinger, endrer du verdien for Hvis en melding oppdages som brukerrepresentasjon for å sette meldingen i karantene.

Kontroller representasjonsinnsikten for å se hva som blokkeres som forsøk på brukerrepresentasjon.

Hvis du vil endre policyene, kan du se Konfigurere policyer for anti-phishing i Defender for Office 365.

Når du har observert resultatene og gjort eventuelle justeringer, går du videre til neste del for å sette meldinger i karantene som oppdages av domenerepresentasjon.

Tune domain impersonation protection

I begge policyene for anti-phishing basert på standardinnstillinger og strenge innstillinger, endrer du verdien for Hvis en melding oppdages som domenerepresentasjon for å sette meldingen i karantene.

Kontroller representasjonsinnsikten for å se hva som blokkeres som forsøk på domenerepresentasjon.

Hvis du vil endre policyene, kan du se Konfigurere policyer for anti-phishing i Defender for Office 365.

Se resultatene, og foreta eventuelle justeringer etter behov.

Trinn 5: Bruke data fra brukerrapporterte meldinger til å måle og justere

Etter hvert som pilotbrukerne rapporterer falske positiver og falske negativer, vises meldingene på fanen Bruker som ble rapportert på innsendingssiden i Microsoft Defender-portalen. Du kan rapportere de feilidentifiserte meldingene til Microsoft for analyse og bruke informasjonen til å justere innstillingene og unntakene i pilotpolicyene etter behov.

Bruk følgende funksjoner til å overvåke og gjenta beskyttelsesinnstillingene i Defender for Office 365:

Hvis organisasjonen bruker en tredjepartstjeneste for brukerrapporterte meldinger, kan du integrere disse dataene i tilbakemeldingssløyfen.

Trinn 6: (Valgfritt) Legg til flere brukere i prøveprosjektet og gjenta

Etter hvert som du finner og løser problemer, kan du legge til flere brukere i testgruppene (og tilsvarende unnta de nye pilotbrukerne fra å skanne av den eksisterende beskyttelsestjenesten etter behov). Jo mer testing du gjør nå, jo færre brukerproblemer må du håndtere senere. Denne "fossefall"-tilnærmingen tillater justering mot større deler av organisasjonen og gir sikkerhetsteamene dine tid til å tilpasse seg de nye verktøyene og prosessene.

  • Microsoft 365 genererer varsler når phishing-meldinger med høy visshet tillates av organisasjonspolicyer. Hvis du vil identifisere disse meldingene, har du følgende alternativer:

    Rapporter eventuelle falske positiver til Microsoft så tidlig som mulig gjennom administratorinnsendinger, og bruk funksjonen Tillat/blokkeringsliste for leier til å konfigurere klarerte overstyringer for de falske positivene.

  • Det er også lurt å undersøke unødvendige overstyringer. Med andre ord, se på dommene som Microsoft 365 ville ha gitt på meldingene. Hvis Microsoft 365 gjentok den riktige dommen, reduseres eller elimineres behovet for overstyring betraktelig.

Trinn 7: Utvide Microsoft 365-beskyttelsen til alle brukere og slå av SCL=-1-regelen for e-postflyt

Gjør trinnene i denne delen når du er klar til å bytte MX-postene slik at de peker til Microsoft 365.

  1. Utvide pilotpolicyene til hele organisasjonen. Det finnes i bunn og grunn forskjellige måter å utvide policyene på:

    • Bruk forhåndsinnstilte sikkerhetspolicyer og del brukerne mellom standardbeskyttelsesprofilen og streng beskyttelsesprofilen (kontroller at alle er dekket). Forhåndsinnstilte sikkerhetspolicyer brukes før eventuelle egendefinerte policyer som du har opprettet eller noen standardpolicyer. Du kan deaktivere de individuelle pilotpolicyene dine uten å slette dem.

      Ulempen med forhåndsinnstilte sikkerhetspolicyer er at du ikke kan endre mange av de viktige innstillingene etter at du har opprettet dem.

    • Endre omfanget av policyene du opprettet og justerte under prøveprogrammet, slik at alle brukere (for eksempel alle mottakere i alle domener). Husk at hvis flere policyer av samme type (for eksempel anti-phishing-policyer) gjelder for samme bruker (enkeltvis, etter gruppemedlemskap eller e-postdomene), brukes bare innstillingene for policyen med høyest prioritet (lavest prioritetsnummer), og behandlingsstopp for denne policytypen.

  2. Slå av SCL=-1-regelen for e-postflyt (du kan deaktivere den uten å slette den).

  3. Kontroller at de forrige endringene har trer i kraft, og at Defender for Office 365 nå er riktig aktivert for alle brukere. På dette tidspunktet har alle beskyttelsesfunksjonene i Defender for Office 365 nå lov til å handle på e-post for alle mottakere, men denne e-posten har allerede blitt skannet av den eksisterende beskyttelsestjenesten.

Du kan stanse midlertidig på dette stadiet for mer dataregistrering og justering i stor skala.

Trinn 8: Bytte MX-poster

Obs!

  • Når du bytter MX-posten for domenet, kan det ta opptil 48 timer før endringene overføres over hele Internett.
  • Vi anbefaler at du senker TTL-verdien for DNS-postene for å aktivere raskere respons og mulig tilbakerulling (hvis nødvendig). Du kan gå tilbake til den opprinnelige TTL-verdien etter at overgangen er fullført og bekreftet.
  • Du bør vurdere å begynne med å endre domener som brukes sjeldnere. Du kan stanse midlertidig og overvåke før du flytter til større domener. Selv om du gjør dette, bør du likevel kontrollere at alle brukere og domener dekkes av policyer, fordi sekundære SMTP-domener løses til primære domener før policyprogrammet.
  • Flere MX-poster for ett enkelt domene fungerer teknisk sett, slik at du kan ha delt ruting, forutsatt at du har fulgt alle veiledningene i denne artikkelen. Nærmere bestemt bør du kontrollere at policyer brukes for alle brukere, at SCL=-1-e-postflytregelen bare brukes på e-post som passerer gjennom den eksisterende beskyttelsestjenesten, som beskrevet i installasjonstrinn 3: Vedlikeholde eller opprette SCL=-1-e-postflytregelen. Denne konfigurasjonen introduserer imidlertid virkemåte som gjør feilsøking mye vanskeligere, og derfor anbefaler vi det vanligvis ikke, spesielt i lengre perioder.
  • Før du bytter MX-postene, må du kontrollere at følgende innstillinger ikke er aktivert på den inngående koblingen fra beskyttelsestjenesten til Microsoft 365. Koblingen vil vanligvis ha én eller flere av følgende innstillinger konfigurert:
    • og krever at emnenavnet på sertifikatet som partneren bruker til å godkjenne med Office 365 samsvarer med dette domenenavnet (RestrictDomainsToCertificate)
    • Avvis e-postmeldinger hvis de ikke sendes fra dette IP-adresseområdet (RestrictDomainsToIPAddresses) Hvis koblingstypen er Partner og en av disse innstillingene er aktivert, vil all e-postlevering til domenene mislykkes etter at du har byttet MX-postene. Du må deaktivere disse innstillingene før du fortsetter. Hvis koblingen er en lokal kobling som brukes for hybrid, trenger du ikke å endre den lokale koblingen. Men du kan fortsatt se etter tilstedeværelsen av en Partner-kobling .
  • Hvis den gjeldende e-postgatewayen også gir mottakervalidering, bør du kontrollere at domenet er konfigurert som autoritativt i Microsoft 365. Dette kan forhindre unødvendige returmeldinger.

Når du er klar, bytter du MX-posten for domenene. Du kan overføre alle domenene samtidig. Eller du kan overføre mindre brukte domener først, og deretter overføre resten senere.

Ta gjerne en pause og evaluere her når som helst. Men husk: Når du slår av SCL=-1-regelen for e-postflyt, kan brukere ha to forskjellige opplevelser for å sjekke falske positiver. Jo før du kan gi en enkelt, konsekvent opplevelse, desto lykkeligere blir brukerne og brukerstøttegruppene når de må feilsøke en manglende melding.

Neste trinn

Gratulerer! Du har fullført overføringen til Microsoft Defender for Office 365! Fordi du har fulgt trinnene i denne overføringsveiledningen, bør de første dagene der e-post leveres direkte til Microsoft 365 være mye jevnere.

Nå starter du normal drift og vedlikehold av Defender for Office 365. Overvåk og se etter problemer som ligner på det du opplevde under prøveprosjektet, men i større skala. Innsikten for forfalskingsintelligens og representasjonsinnsikten er svært nyttig, men vurder å gjøre følgende aktiviteter til en vanlig forekomst: