Sophos Phish Threat: Outlook-Add-in bereitstellen und betreiben

Das Sophos Outlook Add-in gibt Benutzern in Outlook die Aktion Report to Sophos. Es eignet sich sowohl für echte verdächtige Phishing- und Spam-Nachrichten als auch für Phish-Threat-Simulationen. Die Bereitstellung ist erst abgeschlossen, wenn die Weiterleitung an das vorgesehene interne Postfach, die Datenschutzentscheidung und der Benutzerablauf mit einer kontrollierten Nachricht geprüft wurden.

Dieses Add-in gehört zum Melde- und Simulationsablauf von Sophos Phish Threat. Es ist nicht das Verschlüsselungs-Add-in und darf auch nicht mit dem separaten Sophos-Email-Meldeweg verwechselt werden. Dessen abweichenden Scope beschreibt das Runbook zum Report-to-Sophos-Add-in für Sophos Email.

Architektur und Datenschutz vor dem Rollout festlegen

Beim Melden leitet das Add-in die Nachricht an die in Sophos Fusion (ehemals Sophos Central) konfigurierten Postfächer weiter. Standardmässig geht zusätzlich eine Kopie zur Bedrohungsanalyse an SophosLabs. Damit können Administratoren reale Meldungen untersuchen und Sophos kann neue Bedrohungen analysieren. Die Übermittlung kann jedoch Nachrichtentext, Anhänge und personenbezogene oder vertrauliche Inhalte betreffen.

Vor der Aktivierung legt man deshalb gemeinsam mit Datenschutz, Informationssicherheit und gegebenenfalls Arbeitnehmervertretung fest:

welche internen Postfächer Meldungen erhalten und wer darauf zugreifen darf;
wie lange Meldungen aufbewahrt und wie echte Vorfälle bearbeitet werden;
ob eine Kopie an SophosLabs übermittelt werden darf;
welche Benutzerinformation den Lösch- und Übermittlungsablauf erklärt;
mit welcher nicht vertraulichen Nachricht die Abnahme erfolgt.

Soll keine Kopie an SophosLabs gehen, deaktiviert man in der Add-in-Konfiguration Send reported emails to SophosLabs for threat analysis. Das interne Meldepostfach bleibt trotzdem erforderlich. Diese Entscheidung wird vor dem Manifest-Download dokumentiert und nach Konfigurationsänderungen erneut geprüft.

Voraussetzungen und unterstützte Clients prüfen

Erforderlich sind eine aktive Phish-Threat-Umgebung, Zugriff auf Sophos Fusion sowie ein Administrator, der benutzerdefinierte Office-Add-ins in Microsoft 365 beziehungsweise Exchange bereitstellen darf. Vor dem Change dokumentiert man Tenant, Mailplattform, Pilotgruppe, Zielpostfächer, Datenschutzentscheidung und die tatsächlich eingesetzten Outlook-Versionen.

Das aktuelle Add-in ist für folgende Umgebungen vorgesehen:

Microsoft Outlook für Windows und Mac;
Outlook on the web;
Microsoft Outlook für iOS und Android;
Microsoft 365 und unterstützte Exchange-Umgebungen.

Folgende Grenzen müssen vor der Bereitstellung berücksichtigt werden:

Exchange 2013 wird nicht unterstützt.
Nicht-Microsoft-Maildienste wie Gmail sowie andere POP-/IMAP-Konten werden nicht unterstützt.
Das mobile Add-in funktioniert nur mit Microsoft 365 Exchange und nicht mit lokalem Exchange.
Outlook 2019 für Windows und Mac sowie Outlook 2016 für Windows werden nicht unterstützt; diese Einschränkung gilt nicht für das mobile Add-in.

Dass Outlook ein Konto anzeigen kann, belegt also noch keine Add-in-Unterstützung. Kann das Add-in auf Endpoints nicht installiert werden oder fehlt es in der Liste verfügbarer Add-ins, werden zuerst die neuesten Microsoft-Office-Updates installiert.

Meldepostfächer konfigurieren

Die Zielpostfächer werden vor dem Manifest-Download eingerichtet:

In Sophos Fusion das Symbol Global Settings öffnen.
Zu Products and Services > Sophos Phish Threat > Outlook Add-in Configuration wechseln.
Mit Add mailbox das vorgesehene Postfach beziehungsweise eine weitere Failover-Regel hinzufügen.
Zieladressen, Reihenfolge und Zugriff durch das zuständige Security-Team kontrollieren.
Die Option Send reported emails to SophosLabs for threat analysis gemäss der dokumentierten Datenschutzentscheidung setzen.

Eine technisch erreichbare Mailbox reicht nicht: Das zuständige Team benötigt einen definierten Triage-Prozess für echte Meldungen. Für den Pilot verwendet man weder ein persönliches Postfach noch ein unbeaufsichtigtes Sammelpostfach.

Aktuelles XML-Manifest herunterladen

Nach der Postfachkonfiguration:

In Sophos Fusion zu My Products > Phish Threat > Add-in for Outlook gehen.
Unter Outlook Add-In auf Download klicken.
SophosOutlookAddinManifest.xml unverändert an einem zugriffsgeschützten Ort speichern.
Downloadzeitpunkt, verantwortlichen Administrator und vorgesehenen Zuweisungsumfang protokollieren.

Für jede neue Bereitstellung und jedes Upgrade wird das aktuell aus dem eigenen Sophos-Central-Tenant geladene Manifest verwendet. Eine ältere, lokal archivierte XML-Datei ist kein verlässlicher Ausgangspunkt.

Pilot in Microsoft 365 bereitstellen

Sideloading ist nur für Machbarkeitsnachweis und Test eines einzelnen Benutzers vorgesehen. Vor dem Produktiv-Rollout prüft man, ob die zentrale Office-Add-in-Bereitstellung in der Organisation unterstützt wird. Dann wird das aktuelle Manifest zuerst einer kleinen Pilotgruppe zugewiesen:

Am Microsoft 365 Admin Center anmelden.
Settings > Integrated Apps öffnen.
Upload custom apps wählen.
Auf Upload Apps to deploy unter App type die Option Office Add-in auswählen.
Unter Choose how to upload app die Option Upload manifest file (.xml) from device wählen und auf Choose File klicken.
SophosOutlookAddinManifest.xml öffnen. Erst nach der Bestätigung Manifest file validated auf Next klicken.
Auf Add users bei Is this a test deployment die zum Change passende Auswahl treffen. Unter Assign users für den Pilot Specific users/group oder zunächst Just me wählen, nicht sofort Entire organization. Danach Next.
Auf Accept permissions requests auf Accept permissions klicken, die angeforderten Berechtigungen prüfen und im Dialog Permission requested mit Accept bestätigen. Dabei die im tenantbezogenen Manifest beziehungsweise Zustimmungsdialog tatsächlich angezeigten Berechtigungen im Change-Nachweis protokollieren, statt feste Berechtigungsnamen aus einer älteren Anleitung zu übernehmen.
Auf Next und anschliessend auf Review and finish deployment > Finish Deployment klicken.
Nach der Abschlussbestätigung Done wählen. Das Add-in muss unter Integrated Apps > Deployed apps erscheinen.

Status, Manifest, angezeigte und freigegebene Berechtigungen sowie zugewiesene Pilotbenutzer werden als Change-Nachweis festgehalten. Eine neue oder geänderte zentrale Bereitstellung kann laut Microsoft bis zu 24 Stunden für die Verteilung benötigen. Erst nach diesem Fenster beginnt die Fehleranalyse oder eine erneute Bereitstellung. Sind Desktop/Web und – falls vorgesehen – Mobile erfolgreich getestet, erweitert man unter derselben App die Zuweisung schrittweise auf weitere Gruppen oder Entire organization.

In einer lokalen Exchange-Umgebung ohne Verbindung zu Microsoft 365 erfolgt die organisationsweite Installation über das Exchange Admin Center. Diesen Weg nicht mit der Microsoft-365-Bereitstellung mischen. Da das mobile Add-in lokalen Exchange nicht unterstützt, gehört Mobile dort nicht zum Abnahmescope.

Meldung aus Sicht der Benutzer

Outlook-Desktop und Outlook on the web

Die verdächtige Nachricht auswählen beziehungsweise öffnen.
Im Outlook-Menüband auf Report to Sophos klicken.
Die Rückfrage mit Yes bestätigen.

Bei der neuen Outlook-Version für Windows und mehreren konfigurierten Konten erscheint Report to Sophos unter All Apps nur im primären Konto. Das ist eine produktspezifische Grenze und kein Beleg für eine falsche Zuweisung an die weiteren Konten.

Outlook auf iOS und Android

Die Nachricht öffnen.
Das Ellipsensymbol öffnen und Report to Sophos wählen.
Die Rückfrage mit Yes bestätigen.

Nach erfolgreicher Meldung informiert ein Dialog den Benutzer, dass die Nachricht an den Administrator gesendet und aus seinem Postfach gelöscht wurde. Bei einer Phish-Threat-Simulationsnachricht erscheint stattdessen unmittelbar positives Feedback, das die richtige Reaktion bestätigt. Diese beiden Ergebnisse werden in der Benutzerkommunikation erklärt, damit das Löschen einer echten Meldung und das Simulationsfeedback nicht als Fehler interpretiert werden.

Pilot und Produktivbetrieb validieren

Für die Abnahme verwendet man einen Pilotbenutzer und eine eindeutig erkennbare, nicht vertrauliche Nachricht. Eine Simulation wird zusätzlich separat getestet:

Kontrollieren, dass der Benutzer unter Deployed apps tatsächlich zugewiesen ist und das Add-in im vorgesehenen Client erscheint.
Eine normale Testnachricht mit Report to Sophos > Yes melden.
Bestätigen, dass der Erfolgsdialog erscheint und die Nachricht aus dem Benutzerpostfach gelöscht wurde.
Im konfigurierten internen Postfach prüfen, dass genau diese Meldung mit verwendbaren Nachrichtendaten eingegangen ist.
Entsprechend der Datenschutzentscheidung in Sophos Fusion prüfen und dokumentieren, ob die SophosLabs-Übermittlung aktiviert oder deaktiviert ist. Dieser Test bestätigt nur den Konfigurationszustand; die tatsächliche Zustellung einer Kopie an SophosLabs lässt sich damit nicht direkt nachweisen.
Eine freigegebene Phish-Threat-Simulationsmail melden und das unmittelbare positive Feedback in Outlook bestätigen.
Jeden vorgesehenen Clienttyp und bei Mobile ausdrücklich ein Microsoft-365-Exchange-Postfach prüfen.

Ein sichtbarer Button allein ist keine erfolgreiche Abnahme. Ebenso belegt der Eingang im internen Postfach nicht, dass Simulationsfeedback, Löschung und Datenschutzoption korrekt funktionieren.

Rollback und Abbruchkriterien

Vor dem Pilot werden der freigegebene Zuweisungsumfang, die Zielpostfächer und der Zustand von Send reported emails to SophosLabs for threat analysis festgehalten. Bei unerwarteter Nachrichtenlöschung, falschem Routing, einer Abweichung von der Datenschutzfreigabe oder einem fehlgeschlagenen Meldetest wird die Ausweitung gestoppt.

Für den Rollback entfernt man die Pilotzuweisung oder die neue App unter Settings > Integrated Apps. Zielpostfächer und SophosLabs-Option werden nur dann auf den dokumentierten Ausgangszustand zurückgesetzt, wenn sie im selben Change geändert wurden. Anschliessend wartet man die Microsoft-Verteilungszeit von bis zu 24 Stunden ab und prüft in allen betroffenen Clients, dass Report to Sophos nicht mehr angeboten wird. Bereits abgesendete Meldungen können noch eintreffen; nach dem dokumentierten Abbruchzeitpunkt darf jedoch keine neue Testmeldung mehr ausgelöst werden.

Bei einem Upgrade wird das veraltete Add-in nicht erneut bereitgestellt. Bis die aktuelle Bereitstellung korrigiert ist, verwenden Benutzer einen freigegebenen alternativen Meldeweg; der Fehler wird mit den unten genannten Nachweisen eskaliert.

Altes Add-in auf die aktuelle Version migrieren

Für ein Upgrade wird das alte Add-in entfernt und anschliessend das aktuell aus dem eigenen Sophos-Central-Tenant heruntergeladene Manifest bereitgestellt. Statische Versionsnummern oder Angaben zu einzelnen Tokenverfahren sind kein verlässliches Auswahlkriterium, weil sich die von Sophos ausgelieferte Version ändern kann. Das lokal archivierte Manifest wird deshalb nicht wiederverwendet – auch nicht für lokale Exchange-Umgebungen.

Ein altes Add-in wird nicht überinstalliert:

Im Microsoft 365 Admin Center Settings > Integrated Apps öffnen.
Das alte Add-in Report Message auswählen, damit der Flyout geöffnet wird.
Remove App anklicken.
Die Auswahl mit X bestätigen und den Flyout schliessen.
Das aktuelle Manifest erneut aus Sophos Fusion herunterladen und nach dem oben beschriebenen Pilotverfahren bereitstellen.

Eine dauernde Ladeanzeige beim Melden oder fehlgeschlagene Übermittlungen können auf eine veraltete Bereitstellung hinweisen. Die belastbare Korrektur besteht nicht in der Suche nach einem bestimmten Skriptnamen, Banner oder einer fest eingetragenen Versionsnummer: Man entfernt das alte Add-in, lädt das Manifest erneut aus Sophos Fusion herunter, stellt es einer Pilotgruppe bereit und führt den kontrollierten Meldetest durch.

Fehler eingrenzen und Zuständigkeit trennen

Add-in fehlt nur bei einzelnen Benutzern: Eine neue oder geänderte zentrale Bereitstellung kann bis zu 24 Stunden bis zur Anzeige benötigen. Nach Ablauf dieses Fensters Zuweisung unter Deployed apps, primäres Konto bei New Outlook, Postfachtyp, Clientversion und Office-Updates prüfen. Danach Outlook vollständig neu starten. Sideloading nicht als dauerhaften Ersatz für eine fehlerhafte zentrale Zuweisung verwenden.

Add-in fehlt bei der gesamten Pilotgruppe: Auch hier zunächst das Verteilungsfenster von bis zu 24 Stunden berücksichtigen. Danach Manifestprüfung, die im Zustimmungsdialog angezeigten und freigegebenen Berechtigungen, Deploymentstatus und zentrale Bereitstellungsfähigkeit in Microsoft 365 kontrollieren. Bei lokalem Exchange sicherstellen, dass die Installation tatsächlich über das Exchange Admin Center erfolgte. Das ist die Microsoft-/Exchange-Bereitstellungsgrenze; eine Änderung an den Sophos-Zielpostfächern behebt keine fehlende App-Zuweisung.

Meldung lädt endlos oder schlägt in Exchange Online fehl: Prüfen, ob noch das alte Add-in Report Message oder ein archiviertes Manifest verteilt ist. Altes Add-in entfernen, das aktuelle Manifest neu aus Sophos Fusion herunterladen, einer Pilotgruppe bereitstellen und nach Berücksichtigung der Microsoft-365-Verteilungszeit erneut testen. Nicht durch wiederholtes Klicken oder eine sofortige organisationsweite Neuverteilung eine veraltete Bereitstellung kaschieren.

Meldung wird abgeschickt, erreicht aber das Security-Team nicht: Zielpostfächer und Failover-Regeln unter Products and Services > Sophos Phish Threat > Outlook Add-in Configuration prüfen. Mailrouting und Zugriff auf das Zielpostfach gehören zur Mailplattform; Inhalt, SophosLabs-Option und Simulationserkennung zum Phish-Threat-Ablauf.

Simulation zeigt kein positives Feedback: Zuerst bestätigen, dass genau die aktive Phish-Threat-Simulationsnachricht gemeldet wurde. Kommt eine normale Meldung intern an, liegt der Fehler nicht mehr primär bei Manifest oder Zuweisung; Kampagne und Nachrichtenidentität werden dann in Phish Threat geprüft.

Für eine Eskalation sammelt man Tenant, Benutzer und Gruppe, Mailplattform, Outlook-Plattform und exakte Version, Kontoart, Manifest-Downloadzeit, Deployment- und Zuweisungsstatus, Zeitpunkt mit Zeitzone, Ergebnis einer normalen Meldung und einer Simulation, Zielpostfach, SophosLabs-Einstellung sowie beobachtete Dialoge oder Fehler. Keine vertraulichen Nachrichtentexte, Anhänge, Zugangsdaten oder vollständigen Tokens in das Fehlerprotokoll aufnehmen.