Delen via

Overwegingen voor het integreren van niet-Microsoft-beveiligingsservices met Microsoft 365

Hoewel Microsoft een uitgebreid platform biedt voor e-mailbeveiliging, begrijpen we dat sommige klanten een diepgaande strategie voor beveiliging van e-mail gebruiken door een beveiligingsservice van derden (niet van Microsoft) toe te voegen. Er zijn twee overwegingen voor het opnemen van niet-Microsoft-beveiligingsservices met Microsoft 365:

  • Of de niet-Microsoft-service de beveiligingspostuur van uw organisatie verhoogt en de afwegingen hiervoor. Bijvoorbeeld:

    • Meer kosten.
    • Meer complexiteit.
    • Het aantal fout-positieven (goede items gemarkeerd als slecht) neemt toe naarmate er meer producten worden toegevoegd.
    • Hoe de niet-Microsoft-beveiligingsservice end-to-end integreert. Bijvoorbeeld:
      • De niet-Microsoft-service moet een gebruikerservaring bieden waarvoor gebruikers niet hoeven na te denken over welke quarantaine ze moeten gebruiken.
      • De niet-Microsoft-service moet worden geïntegreerd met bestaande SecOps-processen (Security Operations) en hulpprogramma's. Bijvoorbeeld SIEM (Security Information and Event Management), security orchestration, automation and response (SOAR), enzovoort.

    Opmerking

    Email beveiliging is een adversarial-ruimte. Met de opkomst van commodity phishing- en aanvalskits ontwikkelen aanvallen zich snel en veranderen ze snel. Daarom maakt Microsoft Defender voor Office 365 deel uit van Microsoft Defender XDR, onze multi-layered, pre-breach en post-breach benadering van enterprise cyber security.

    Het maakt niet uit hoeveel lagen van e-mailbeveiliging er bestaan, de totale beveiliging bereikt nooit 100 procent.

  • Hoe de niet-Microsoft-service e-mailberichten scant en erop reageert. Niet-Microsoft-beveiligingsservices stellen doorgaans de volgende drie integratieopties voor, en niet al deze opties kunnen op dit moment even goed door Microsoft worden ondersteund.

Integratie via DNS-e-mailroutering (MX-record verwijst naar de niet-Microsoft-service)

Deze configuratie wordt uitgebreid beschreven in Uitgebreide filtering voor connectors in Exchange Online en wordt volledig ondersteund door Microsoft. Email beveiligingsleveranciers die ondersteuning bieden voor geverifieerde ontvangen keten (ARC) werken het beste, maar er zijn beperkingen. Vermijd bijvoorbeeld het gebruik van veilige koppelingen om koppelingen te controleren en te verpakken met een niet-Microsoft-service die ook koppelingen herschrijft. Dubbele koppelingsterugloop kan voorkomen dat Veilige koppelingen de status van de koppeling valideren, koppelingen ontploppen voor bedreigingen en mogelijk eenmalige gebruikskoppelingen activeren. We raden u aan de functie voor koppelingsterugloop uit te schakelen in de niet-Microsoft-service.

Zie E-mailstroom beheren met behulp van een cloudservice van derden met Exchange Online voor meer informatie over deze configuratie.

Integratie via de Microsoft Graph API

Sommige niet-Microsoft-services verifiëren en gebruiken de Microsoft Graph API om berichten te scannen nadat ze zijn bezorgd in postvakken van gebruikers. Met deze configuratie kan de niet-Microsoft-service ook berichten verwijderen waarvan ze denken dat ze kwaadaardig of ongewenst zijn. Deze configuratie vereist doorgaans volledige toegang tot postvakken door de niet-Microsoft-service. Zorg ervoor dat u de beveiligings- en ondersteuningspraktijken van de niet-Microsoft-service begrijpt voordat u deze machtiging verleent.

Integratie via in- en uitgaande e-mailroutering

Met deze configuratie kan de MX-record verwijzen naar Microsoft 365. De niet-Microsoft-service werkt echter na Microsoft 365-e-mailbeveiliging en -verwerking, zoals wordt weergegeven in het volgende diagram:

diagram van de e-mailstroom met een niet-Microsoft-beveiligingsservice die wordt gebruikt na de bezorging van e-mail naar Microsoft 365.

Tip

Verbeterde filtering voor connectors werkt niet met deze configuratie. Verbeterde filtering voor connectors is ontworpen voor scenario's waarbij de niet-Microsoft-service zich vóór Microsoft 365 bevindt, zoals eerder is uitgelegd in de sectie Integratie via DNS-e-mailroutering . Met de niet-Microsoft-service vóór Microsoft 365 kan de volledige e-mailbeveiligingsstack werken, terwijl spoofing van fout-positieven met betrekking tot de verzendinfrastructuur van de niet-Microsoft-service op intelligente wijze wordt voorkomen. U kunt verbeterde filtering voor connectors niet gebruiken om alle berichten van Microsoft 365 IP-adressen te vertrouwen.

Voor deze configuratie moet het bericht de grens van de Microsoft 365-service verlaten. Wanneer het bericht wordt geretourneerd vanuit de niet-Microsoft-service, wordt het door Microsoft 365 behandeld als een volledig nieuw bericht. Dit gedrag resulteert in de volgende problemen en complexiteiten:

  • Berichten worden tweemaal geteld in de meeste rapportagehulpprogramma's, waaronder Explorer (Threat Explorer), Geavanceerde opsporing en geautomatiseerd onderzoek en respons (AIR). Dit gedrag maakt het moeilijk om het berichtoordeel en de acties goed te correleren.

  • Omdat berichten die terugkeren naar Microsoft 365 waarschijnlijk niet kunnen worden gecontroleerd op e-mailverificatie, kunnen de berichten worden geïdentificeerd als spoofing (fout-positieven). Sommige niet-Microsoft-services raden het gebruik van e-mailstroomregels (transportregels) of filteren van IP-verbindingen aan om dit probleem op te lossen, maar dit kan leiden tot fout-negatieven.

  • Misschien wel het belangrijkste is dat machine learning in Defender voor Office 365 niet zo effectief werkt als mogelijk. Machine learning-algoritmen zijn afhankelijk van nauwkeurige gegevens om beslissingen te nemen over inhoud. Inconsistente of gewijzigde gegevens kunnen een negatieve invloed hebben op het leerproces, wat leidt tot een afname van de algehele effectiviteit van Defender voor Office 365. Voorbeelden zijn:

    • Reputatie: Na verloop van tijd ontdekken de machine learning-modellen de elementen die zijn gekoppeld aan goede en slechte inhoud (IP-adressen, verzendende domeinen, URL's, enzovoort). Wanneer berichten worden geretourneerd van de niet-Microsoft-service, blijven de eerste verzendende IP-adressen niet behouden en kan de effectiviteit van IP-adressen bij het weergeven van een juist oordeel worden verminderd. Dit gedrag kan ook van invloed zijn op inzendingen, die later in punt 3 worden besproken.
    • Wijzigingen in berichtinhoud: veel e-mailbeveiligingsservices voegen berichtkoppen toe, voegen disclaimers toe, wijzigen de inhoud van de berichttekst en/of herschrijven URL's in berichten. Hoewel dit gedrag meestal geen probleem is, kunnen bezorgde berichten met deze wijzigingen die later worden vastgesteld als schadelijk en verwijderd via zero-hour auto purge (ZAP) machine learning leren dat deze wijzigingen duiden op een slecht bericht.

Om deze redenen raden we u ten zeerste aan deze configuratie te vermijden en samen te werken met de niet-Microsoft-serviceleverancier om de andere integratieopties te gebruiken die in dit artikel worden beschreven. Als u deze configuratie echter moet gebruiken, raden we u ten zeerste aan de volgende instellingen en bewerkingen te gebruiken om uw beveiligingspostuur te maximaliseren:

  1. Configureer Defender voor Office 365 beleidsacties om alle negatieve uitspraken in quarantaine te plaatsen. Hoewel deze configuratie minder gebruiksvriendelijk kan zijn dan het gebruik van de map Ongewenste e-mail Email, vindt de actie ongewenste e-mail alleen plaats na de definitieve levering in het postvak. Een e-mail die in de map Ongewenste Email zou zijn bezorgd, wordt in plaats daarvan verzonden naar de niet-Microsoft-service. Als/wanneer dit bericht terugkomt naar Microsoft, is er geen garantie dat het oorspronkelijke oordeel (bijvoorbeeld spam) behouden blijft. Dit gedrag leidt tot een lagere algehele effectiviteit.

    Tip

    E-mailstroomregels (transportregels) die naar oorspronkelijke uitspraken kijken, zijn niet ideaal, omdat ze andere problemen kunnen veroorzaken en kunnen leiden tot problemen met de effectiviteit.

  2. Minimaliseer fout-positieven door spoof voor e-mail die afkomstig is van de niet-Microsoft-service te overschrijven. Als de niet-Microsoft-service bijvoorbeeld een IP-adres heeft van 172.17.17.35, maakt u twee toegestane vervalste afzendervermeldingen in de lijst Tenant toestaan/blokkeren: één extern en één intern, zoals wordt weergegeven in de volgende schermopname:

    Een schermopname van de toegestane vervalste afzendervermeldingen in de lijst Tenant toestaan/blokkeren.

    Verwijder deze onderdrukkingsvermeldingen als u ooit de niet-Microsoft-beveiligingsservice verlaat of de werking ervan wijzigt.

  3. Fout-negatieve e-mail (slechte e-mail toegestaan) en fout-positieve e-mailinzendingen aan Microsoft moeten afkomstig zijn van de eerste versie van het bericht, niet van de versie die wordt geretourneerd vanuit de niet-Microsoft-service. Fout-positieven die worden toegeschreven aan de niet-Microsoft-service, moeten worden verzonden naar de niet-Microsoft-service. Deze vereiste kan complex zijn om te beheren:

    • Microsoft-fout-negatief (gemist bij de eerste ontvangst): u hebt een kopie van het bericht nodig voordat het in het postvak wordt bezorgd. Verzend de kopie in quarantaine vanuit de niet-Microsoft-service, als deze beschikbaar is.
    • Microsoft + niet-Microsoft-service fout-negatief: als beide services dit missen, raden we u aan het oorspronkelijke item aan Microsoft te rapporteren en het item in het postvak van de geadresseerde te rapporteren aan de niet-Microsoft-service. Het item dat vanuit de niet-Microsoft-service wordt geretourneerd naar Microsoft 365, bevat details van de niet-Microsoft-service (bijvoorbeeld het verzenden van IP-adressen van de niet-Microsoft-service, aangepaste headers, enzovoort), wat kan leiden tot een verminderde effectiviteit van Machine Learning.
    • Microsoft fout-positief: als het bericht in eerste instantie door Microsoft is opgevangen vóór de evaluatie door de niet-Microsoft-service, is het verzenden van deze kopie uit quarantaine effectief.
    • Niet-Microsoft-service fout-positief: als de niet-Microsoft-service het bericht heeft ondervangen, moet u het bericht naar hen verzenden, omdat Microsoft het probleem niet kan oplossen.

Niet-Microsoft-hulpprogramma's voor berichtrapportage integreren

Defender voor Office 365 heeft door de gebruiker gerapporteerde instellingen die werken met de ingebouwde knop Rapport in ondersteunde versies van Outlook.

Wetende dat niet-Microsoft-beveiligingsservices hun eigen hulpprogramma's en processen kunnen bevatten voor het melden van fout-positieven en fout-negatieven (inclusief gebruikersopvoeding/-bewustwording), ondersteunt Defender voor Office 365 inzendingen van rapportageprogramma's van derden. Deze ondersteuning helpt bij het stroomlijnen van het melden van fout-positieven en fout-negatieven aan Microsoft en stelt uw SecOps-team in staat om te profiteren van Microsoft Defender XDR incidentbeheer en geautomatiseerde onderzoeken en reageren (AIR).

Zie Opties voor rapportagehulpprogramma's van derden voor meer informatie.