Warum muss man uns whitelisten?

Damit die Benachrichtigungen und Trainings-E-Mails der Phishing-Simulation bei den Empfängern
ankommen und Klicks auf Dateianhänge und Links ordnungsgemäß gezählt werden, ist es m.U.
notwendig, Ihre Sicherheits- und Filtersysteme auf die Training-E-Mails vorzubereiten und entsprechend
zu konfigurieren.
Durch Whitelisting stellen Sie sicher, dass die E-Mails nicht automatisch an Junk- oder Spamordner
weitergeleitet werden oder Sandboxes die zu messenden Ergebnisse verfälschen.

Welche Systeme muss ich beim Whitelisting bedenken?

Das ist natürlich abhängig von Ihrer Netzwerklandschaft und den von ihnen genutzten
Sicherheitssysteme wie E-Mail-, Spam-Filter, Secure Gateways oder Proxy Server.
Damit die Trainings-E-Mails die Mitarbeitenden erreichen können, müssen Sie zunächst alle
Sicherheitssysteme identifizieren, die sich vor dem Mailserver befinden. Diese Systeme müssen
entsprechend konfiguriert werden.

Abb1: Einfache Systemlandschaft:

Abb2: Komplexe Systemlandschaft:

Es kann vorkommen das Sie zusätzliche Informationen in ihren Sicherheitssystemen hinterlegen müssen,
z.B. wenn Sie Endpoint-Lösungen haben (Sandboxing, Client-Firewalls, URL-Filter etc). Hier benötigen
Sie zusätzlich eine Domain bzw. URL-Liste. Diese können Sie über die bekannten Support Kanäle
anfordern.

Welche Möglichkeiten des Whitelistings existieren?

Sie haben vier Möglichkeiten unseren Mailserver in ihren Sicherheitssystemen zu whitelisten:

1. Whitelisting der IP: 84.16.227.187
Das ist die von uns favorisierte Konfigurationsmethode. In vielen Systemen finden Sie die
Möglichkeit die IP von IT-Seal zu hinterlegen. Unsere E-Mails werden sämtlich über die IP
84.16.227.187 versendet.

• Vorteil: Mit dieser Methode ermöglichen Sie eine direkte Zustellung der Trainings-E-Mails.
• Nachteil: Wird anscheinend von weniger Systemen unterstützt als gedacht. Sollten ihre Systeme nicht die Anforderungen erfüllen, können sie die unten beschriebenen Möglichkeiten nutzen.

2. Zustellung am Sicherheitssystem vorbei
Neben der Nutzung des MX records um den empfangenden Server einer Domain zu ermitteln
gibt es auch die Möglichkeit einen festen Server pro Training bei uns zu hinterlegen. Siehe
hierzu auch Abbildung 3. Falls dies eingerichtet werden soll, melden Sie sich bitte über den
Ihnen bekannten Support Kanal.

• Vorteil: Die E-Mails werden an den vorgeschalteten Sicherheitssystemen vorbei zugestellt. Außerdem
  ist es möglich sich hier mit Nutzername und Passwort am Mailserver direkt zu identifizieren.
• Nachteil: Es kann nur ein Server für das komplette Training ausgewählt werden, dies ist entsprechend nicht nutzbar, wenn verschiedene E-Mail Domains mit verschiedenen Servern verwendet werden sollen.
  Außerdem müssen die entsprechenden Whitelisting Einstellungen immer noch am Mailserver
  vorgenommen werden

Abb3: E-Mailzustellung an den Sicherheitssystemen vorbei.

3. Whitelisting der Absender-Domain: z.B. help.it-security.lt-seal-index.de
Das Whitelisting kann hier über Basisdomains erfolgen, hierfür muss Ihr Sytem Wildcard Domains zulassen (z.B. *.lt-seal-index.de) oder aber über eine vollständige Absenderliste.
Beide können Sie über die bekannten Support Kanäle anfordern.

• Vorteil: Jedes Training hat eine Liste aller Domains, über die wir Trainings-E-Mails verenden. Als auch
  eine Liste mit allen Links, die in den Trainings-Mails hinterlegt sind.
• Nachteil: Bei Sicherheitssystemen ohne Import oder Wildcard-Funktion ist es sehr mühsam alle
  Domains/-Links ins System zu integrieren, da je nach Trainingsumfang kann die Listen bis zu 5000
  Zeilen umfassen.

4. Header-basiertes Whitelisting: z.B. X-ITSEAL: ichbineinheaderderextrafuerdiesestraininggesetztwird
Diese Form des Whitelisting wird von uns nicht präferiert, ist aber i.d.R. in den allermeisten Sicherheitssystemen anwendbar. Hierfür wird ein speziell für Ihr Training generierter Header
benötigt. Er kann über die bekannten Support Kanäle angefordert werden.

• Vorteil: In den meisten Sicherheitssystemen umsetzbar.
• Nachteil: Da der Header-String missbraucht werden kann, birgt das Whitelisting über Header ein nicht unerhebliches Sicherheitsrisiko.