Ein sinnvoller Sicherheitsstandpunkt

Wenn Sie E-Mail-Sicherheitstools evaluieren, sollten Sie nicht zwischen einem fairen Test und der Sicherheit Ihrer Benutzer wählen müssen. Doch irgendwie ist das die Forderung geworden.

Hier ist ein Muster, das wir gesehen haben. Unternehmen führen einen Vergleich zwischen reinen API-Tools und SEG-Lösungen durch. Dann schlägt jemand vor, die wichtigsten Schutzmechanismen der SEG (URL-Rewriting, Attachment-Kontrollen, fortgeschrittene Bedrohungsrichtlinien) zu deaktivieren, um "ein gleiches Spielfeld zu bieten."

Damit wird nichts nivelliert, sondern das Feld wird einfach komplett entfernt.

Lassen Sie uns darüber sprechen, wie Sie diese Architekturen ehrlich bewerten können, ohne ein Risiko einzugehen, und warum die Eigenheiten des reinen API-Designs diese Diskussion überhaupt erst notwendig machen.

Zwei Architekturen, unterschiedliche Aufgaben

Die Hauptunterschiede in der Architektur sind nicht nur technischer Natur, sondern sie bestimmen auch, was jede Lösung schützen kann und was nicht.

SEGs sitzen inline. Sie prüfen jede Nachricht vor der Zustellung, analysieren Links und Anhänge in Echtzeit und setzen Kontrollen an der Peripherie durch. (Wenn etwas gefährlich ist, landet es nie im Posteingang.) Sie prüfen jede URL oder jeden Anhang, sobald der Benutzer darauf klickt, und bieten so eine weitere Sicherheitsebene gegen dynamische Bedrohungen.

Reine API-Tools stellen nach der Lieferung eine Verbindung her. Sie beobachten, was in Microsoft 365 oder Google Workspace landet, analysieren Verhaltensmuster und versuchen, manchmal Minuten oder Stunden später, über API-Aufrufe Abhilfe zu schaffen.

Eine verhindert. Einer antwortet. Beides kann wertvoll sein. Aber sie sind nicht austauschbar, und um sie nebeneinander zu bewerten, muss man wissen, was jede Architektur tatsächlich leisten kann.

Warum jemand Sie bitten könnte, Ihre SEG zu schwächen

Wenn ein API-Tool hinter einer vollständig konfigurierten SEG ausgeführt wird, passiert etwas Vorhersehbares: Die meisten Bedrohungen schaffen es nie bis zur Analysephase.

Commodity-Malware wird blockiert. Bekannte Phishing-Kampagnen enden an der Pforte. Offensichtliche Nachahmungsversuche kommen nicht durch. Was für das API-Tool zur Analyse übrig bleibt, ist ein deutlich kleinerer, sauberer Datensatz.

Das ist das ideale Sicherheitsergebnis: mehrere Schichten arbeiten zusammen, wobei die gefährlichsten Dinge frühzeitig gestoppt werden. Aber das macht es für einen reinen API-Anbieter schwieriger, den Wert während einer kurzen Bewertung zu demonstrieren.

Die Abhilfe lautet also: Deaktivieren Sie die effektivsten Kontrollen der SEG, lassen Sie mehr durch und erstellen Sie mehr "Erkennungen" zu melden.

Das Problem? Sie haben gerade Ihre Umgebung für die Dauer des Tests nachweislich unsicherer gemacht.

Was Sie tatsächlich verlieren, wenn Sie die Dinge herunterfahren

Dies ist kein hypothetisches Risiko. Die Schwächung Ihrer SEG entfernt den Schutz in drei Phasen, in denen Angriffe erfolgreich sind oder scheitern:

Vor der Auslieferung: Drohungen am Tor stoppen

Wenn eine SEG vollständig aktiviert ist, gelangen gefährliche E-Mails nie in den Posteingang. Deep Inspection fängt bösartige URLs und Anhänge ab. Nachahmungstechniken werden identifiziert. Drohungen werden vor der Zustellung blockiert. Wenn Sie diese Kontrollen lockern, überschwemmen Sie Microsoft 365 mit Inhalten, die dort nicht sein sollten. Das API-Tool kann erst nach der Zustellung reagieren, wenn die Nachricht bereits sichtbar, lesbar und verwertbar ist. Selbst eine 30-sekündige Verzögerung bedeutet 30 Sekunden unnötige Belichtung.

Klickzeit: Schutz von Nutzern, wenn sie sich engagieren

Das Umschreiben von URLs gehört zu Ihren wertvollsten Kontrollen. Wenn Benutzer auf Links klicken, wird eine richtig konfigurierte SEG:

• Leitet Klicks durch Echtzeit-Inspektion
• Folgt Umleitungen zu endgültigen Zielen
• Analysiert Seiten auf Engagement
• Blockiert den Zugriff auf Websites, die nach Eingang der E-Mail als bösartig eingestuft wurden

Wenn Sie diese Funktion während eines PoV deaktivieren, klicken sich die Benutzer direkt zu dem Ziel durch, das der Angreifer ausgewählt hat. Reine API-Tools können die Klicks nicht abfangen. Sie können nur versuchen, die E-Mail im Nachhinein zurückzuholen, vorausgesetzt, die API-Verbindung funktioniert, die Verarbeitung durch Microsoft verzögert sich nicht und der Benutzer hat seine Anmeldedaten noch nicht preisgegeben. Das ist verkehrt herum.

Intern und nach außen: Wo API-only-Tools im Dunkeln tappen

API-Tools analysieren in der Regel eingehende E-Mails von externen Absendern. Was sie nicht kontrollieren können, ist das, was innerhalb Ihrer Organisation passiert, wo kompromittierte Konten und laterales Phishing operieren. Eine SEG, die interne und ausgehende Kommunikation schützt, fängt:

• Seitliches Phishing von kompromittierten Konten, das auf Kollegen abzielt
• Datenexfiltration an externe Adressen
• Böswillige Insider-Aktivitäten über legitime Konten
• Richtlinienverstöße bezüglich dessen, was Ihre Umgebung verlässt

Diese Angriffe verwenden autorisierte Konten und vertrauenswürdige Domänen und berühren niemals den externen E-Mail-Verkehr. Reine API-Tools, die eingehende Nachrichten beobachten, werden sie völlig übersehen.

Wie man einen fairen PoV betreibt, ohne etwas kaputt zu machen

Sie müssen keine Kompromisse bei der Sicherheit eingehen, um Anbieter sinnvoll zu bewerten. Sie brauchen bessere Erfolgskriterien.

Halten Sie Ihre SEG vollständig aktiviert

Jeder Anbieter, der von Ihnen verlangt, dass Sie bestehende Schutzmechanismen abschwächen, demonstriert keinen Wert, sondern stellt ihn nur her. URL-Rewriting, Sandboxing für Anhänge und Bedrohungsrichtlinien sollten während der gesamten Bewertung aktiv bleiben.

Messen Sie die Exposition, nicht nur die Anzahl der Entdeckungen

Fragen Sie jeden Verkäufer:

• Wie lange war die Bedrohung für die Benutzer sichtbar?
• Was passiert, wenn die API-Konnektivität nachlässt?
• Können Sie Klicks verhindern, oder nur hinterher aufräumen?

Eine Erkennung, die erfolgt, nachdem ein Benutzer die Anmeldedaten gelesen, angeklickt und eingegeben hat, ist keine Prävention. Es ist eine Reaktion auf Vorfälle.

Bewerten Sie die vollständigen Sicherheitsergebnisse

Vergleichen Sie, was die einzelnen Anbieter tatsächlich einstellen:

• SEG-Lösungen: Blockieren Sie Bedrohungen vor der Zustellung, schützen Sie Klicks in Echtzeit, beheben Sie Probleme nach der Zustellung, kontrollieren Sie ausgehende und interne E-Mails
• Reine API-Tools: Analysieren Sie eingehende Nachrichten nach der Zustellung, wenn die APIs dies zulassen.

Einer davon ist ein umfassender Plattformschutz. Die andere ist eine zusätzliche Schicht.

Wie eine gute Bewertung aussieht

Das Ziel ist nicht, einen Anbieter schlecht aussehen zu lassen oder ein künstliches Szenario zu schaffen, in dem alle erfolgreich sind. Es geht darum, zu verstehen, was jede Lösung zu Ihrer Sicherheit beiträgt und wo Lücken bestehen.

Wenn Sie ein reines API-Tool evaluieren, testen Sie es in einer realistischen Konfiguration. Führen Sie es hinter Ihrer bestehenden SEG aus, wobei alles aktiviert ist. Messen Sie, wie es mit den raffinierten Bedrohungen umgeht, die Ihre erste Verteidigungslinie überwinden. Verstehen Sie, was es nicht kann, wie z.B. Schutz während der Klickzeit, interne Bedrohungen und Outbound-Kontrollen. Entscheiden Sie dann, ob diese zusätzliche Analyse die Investition und den betrieblichen Aufwand für die Verwaltung einer weiteren Lieferantenbeziehung rechtfertigt.

Oder lassen Sie Ihren umfassenden Schutz auf Plattformebene weiterlaufen und lassen Sie ihn das tun, was er am besten kann: Bedrohungen vor, während und nach der Zustellung in Ihrer gesamten E-Mail-Umgebung stoppen.

Machen Sie Ihre PoVs intelligenter

Punktlösungen lösen Punktprobleme. Plattformen lösen das gesamte Problem.

Wenn eine Bewertung eine Schwächung Ihrer heutigen Schutzmaßnahmen erfordert, ist das ein Signal, das Sie beachten sollten. Sicherheitstools sollten sich durch ihre eigenen Leistungen bewähren und nicht durch die Benachteiligung der Konkurrenz.

Machen Sie Ihre PoVs intelligenter. Sorgen Sie für die Sicherheit Ihrer Benutzer. Und wenn jemand vorschlägt, das URL-Rewriting zu deaktivieren, um die Dinge "fairer zu gestalten," ist das vielleicht ein guter Zeitpunkt, um zu fragen, was normalerweise passiert, wenn ungewöhnliche Anfragen gestellt werden.