Out-of-Band-Kommunikation: Sichere Kommunikation bei Cyberangriffen und IT-Ausfällen

Das Wichtigste auf einen Blick

Out-of-Band-Kommunikation (OOB-Kommunikation) bezeichnet die Nutzung eines unabhängigen Kommunikationskanals, wenn reguläre Unternehmenssysteme ausgefallen, kompromittiert oder nicht mehr vertrauenswürdig sind. Sie ermöglicht es IT-Abteilungen, Sicherheitsteams und Führungskräften, auch während eines Cyberangriffs oder einer größeren IT-Störung Entscheidungen abzustimmen.

Im Gegensatz zu gewöhnlichen Backup-Messengern muss eine OOB-Lösung von den kritischen Abhängigkeiten des primären Kommunikationssystems getrennt sein. Ein zweiter Messenger bietet beispielsweise keinen ausreichenden Schutz, wenn beide Plattformen denselben ausgefallenen Identitätsanbieter oder dieselbe Netzwerkverbindung benötigen.

Die wichtigsten Eigenschaften einer OOB-Kommunikationslösung:

• Unabhängige Infrastruktur: Betrieb getrennt von den Systemen, die bei einem Vorfall ausfallen können.
• Alternative Authentifizierung: Zugriff auch dann möglich, wenn der primäre Identitätsanbieter oder das Unternehmens-SSO nicht verfügbar ist.
• Geschützte Kommunikation: Verschlüsselung, Zugriffskontrolle und geeignete Regeln für vertrauliche Informationen.
• Vorbereiteter Notfallzugang: Benutzerkonten, Geräte und Kontaktlisten sind bereits vor einem Vorfall eingerichtet.
• Mehrere Kommunikationswege: Je nach Risiko können Messenger, Telefonie, unabhängige Mobilfunknetze oder Satellitenverbindungen kombiniert werden.

Welche Lösungen kommen für OOB-Kommunikation infrage?

Lösung	Möglicher OOB-Einsatz	Entscheidende Voraussetzung
TrueConf Server	Separater Unternehmensmessenger mit Sprach- und Videokommunikation	Unabhängiger Serverbetrieb, Authentifizierung und Netzwerkzugang
Mattermost	Zusammenarbeit und Incident Response auf separater Infrastruktur	Vorgefertigte OOB-Umgebung mit unabhängigen Zugängen
Element / Matrix	Föderierte oder isolierte Krisenkommunikation	Getrennte Identitäts- und Serverinfrastruktur
Rocket.Chat	Separater Messenger für IT- und Krisenteams	Unabhängiges Hosting und geeignete Lizenzkonfiguration
Signal	Alternativer verschlüsselter Kommunikationskanal	Erreichbare Geräte und funktionsfähige externe Netzverbindung
Telefonie und Satellitenkommunikation	Sprachkommunikation bei Ausfällen digitaler Unternehmensdienste	Unabhängiger Anbieter, Stromversorgung und Netzabdeckung

Fazit: Eine zweite Kommunikationsanwendung ist noch keine echte OOB-Lösung. Entscheidend ist, ob sie bei einem konkreten Ausfall oder Sicherheitsvorfall tatsächlich unabhängig weiterarbeitet.

Was ist Out-of-Band-Kommunikation?

Out-of-Band-Kommunikation bezeichnet die Übertragung wichtiger Informationen über einen separaten Kommunikationsweg außerhalb der regulären Unternehmensumgebung.

Während des normalen Geschäftsbetriebs verwenden Mitarbeiter beispielsweise Microsoft Teams, Slack, E-Mail oder eine interne Telefonanlage. Diese Dienste bilden die primäre Kommunikationsinfrastruktur.

Wenn ein Cyberangriff oder technischer Defekt diese Infrastruktur beeinträchtigt, benötigt die Organisation einen zweiten, vertrauenswürdigen Weg zur Abstimmung.

Ein typisches Beispiel ist ein Ransomware-Angriff: Die IT-Abteilung vermutet, dass Angreifer Zugriff auf die Unternehmensdomäne und interne Nachrichten haben. Statt die weitere Reaktion über diese möglicherweise überwachten Systeme zu koordinieren, wechselt das Incident-Response-Team auf eine separat betriebene Kommunikationsplattform.

Der Begriff Out-of-Band bedeutet dabei nicht zwingend, dass für jeden Dienst eine physisch getrennte Leitung vorhanden sein muss. Maßgeblich ist die ausreichende technische und organisatorische Unabhängigkeit gegenüber den Risiken, für die der Ersatzkanal vorgesehen ist.

In-Band und Out-of-Band im Vergleich

Kriterium	In-Band-Kommunikation	Out-of-Band-Kommunikation
Einsatz	Regulärer Geschäftsbetrieb	Störungen, Cybervorfälle, vertrauliche Krisenkommunikation
Infrastruktur	Primäre Unternehmenssysteme	Separater oder ausreichend unabhängiger Kommunikationsweg
Anmeldung	Häufig zentrales SSO oder Unternehmensverzeichnis	Vorbereitete unabhängige Authentifizierung
Verfügbarkeit	Abhängig von der normalen IT-Umgebung	Für ausgewählte Ausfallszenarien abgesichert
Benutzerkreis	Häufig alle Mitarbeiter	Vorab definierte Krisen- und Einsatzteams
Hauptziel	Produktive Zusammenarbeit	Sichere Koordination und Handlungsfähigkeit bei Vorfällen

Eine OOB-Plattform ersetzt die reguläre Kommunikation nicht zwangsläufig dauerhaft. Sie stellt einen vorbereiteten alternativen Kanal für Situationen bereit, in denen die normale Umgebung nicht mehr verwendet werden sollte.

Wann braucht ein Unternehmen Out-of-Band-Kommunikation?

Nicht jede IT-Störung rechtfertigt den Wechsel auf einen Notfallkanal. Bei bestimmten Ereignissen kann eine unabhängige Kommunikationsmöglichkeit jedoch entscheidend sein.

Ransomware und kompromittierte Unternehmenssysteme

Bei einem Ransomware-Angriff ist häufig unklar, welche Teile der Infrastruktur bereits betroffen sind.

Wenn Angreifer Zugriff auf E-Mail-Konten, Verzeichnisse oder interne Messenger erhalten haben, können sie möglicherweise die Kommunikation des Sicherheitsteams beobachten.

Ein unabhängiger OOB-Kanal ermöglicht es, Gegenmaßnahmen zu koordinieren, ohne vertrauliche Informationen automatisch über die möglicherweise kompromittierte Umgebung zu übertragen.

Ausfall von Microsoft 365 oder anderen Cloud-Diensten

Unternehmen verwenden häufig mehrere Dienste, die von derselben Cloud- oder Identitätsinfrastruktur abhängen.

Fällt diese gemeinsame Grundlage aus, können gleichzeitig E-Mail, Videokonferenzen und interne Chats betroffen sein.

Ein separates Kommunikationssystem mit eigener Anmeldung kann in einem solchen Szenario weiterhin verfügbar sein.

Dabei muss allerdings auch die Netzwerkverbindung unabhängig genug sein. Ein zweiter Cloud-Dienst hilft nicht, wenn sämtliche Mitarbeiter aufgrund eines lokalen Internetausfalls keinen externen Dienst erreichen können.

Kompromittierung von Active Directory oder SSO

Ein Unternehmen kann mehrere Messenger betreiben, die alle dieselbe Benutzeranmeldung verwenden.

Wenn der zentrale Identitätsanbieter nicht verfügbar oder nicht mehr vertrauenswürdig ist, können dadurch sämtliche Kommunikationsdienste gleichzeitig ausfallen.

Eine geeignete OOB-Umgebung sollte deshalb bereits vorbereitete alternative Zugangsdaten oder einen unabhängigen Identitätsdienst besitzen.

Kritische Infrastrukturen und Produktionsumgebungen

In industriellen Umgebungen müssen Verantwortliche auch während einer Netzwerkunterbrechung miteinander kommunizieren können.

Je nach Einsatzbereich können getrennte Kommunikationsserver, lokale Funknetze, Mobilfunk oder andere Übertragungswege sinnvoll sein.

Entscheidend ist, dass die Notfallkommunikation nicht von denselben Komponenten abhängt wie die beeinträchtigte Produktionsinfrastruktur.

Out-of-Band-Kommunikation: 6 Lösungen und Ansätze im Vergleich

Nicht jede Plattform deckt dieselben Anforderungen ab. Einige eignen sich besonders für die interne Zusammenarbeit während eines Sicherheitsvorfalls, andere als ergänzender Sprachkanal oder für kurzfristige Alarmierungen.

1. TrueConf Server: Separater Kommunikationsserver für Unternehmen

TrueConf Server ist eine selbst gehostete Plattform für Unternehmensmessaging, Sprach- und Videoanrufe sowie Videokonferenzen.

Die Software kann auf einer vom Unternehmen kontrollierten Infrastruktur betrieben werden. Dadurch lässt sich eine separate Kommunikationsumgebung aufbauen, die nicht unmittelbar vom primären Cloud-Messenger abhängig ist.

Wie kann TrueConf für OOB-Kommunikation eingesetzt werden?

Ein Unternehmen verwendet im Normalbetrieb beispielsweise Microsoft Teams. Zusätzlich betreibt es einen TrueConf Server in einer getrennten Infrastruktur für die Notfallkommunikation.

Bei einem Ausfall von Microsoft 365 kann das Krisenteam über TrueConf miteinander kommunizieren, sofern Server, Authentifizierung, Endgeräte und Netzwerkzugang weiterhin erreichbar sind.

Die Plattform ermöglicht unter anderem:

• Einzel- und Gruppenchats.
• Kommunikationskanäle für organisatorische Mitteilungen.
• Sprach- und Videoanrufe.
• Gruppenvideokonferenzen.
• Dateiübertragung und Bildschirmfreigabe.
• Verwaltung von Benutzerkonten und Berechtigungen.
• Integration kompatibler SIP/H.323-Systeme.

Die Vollversion von TrueConf Server kann innerhalb eines privaten Unternehmensnetzes ohne Internetverbindung betrieben werden. Damit eignet sie sich auch für entsprechend vorbereitete isolierte Infrastrukturen.

Welche Abhängigkeiten sind kritisch?

Ein separat installierter TrueConf Server ist nicht automatisch eine vollständig unabhängige OOB-Umgebung.

Wenn die Notfallplattform weiterhin dieselbe Active-Directory-Instanz, denselben SSO-Dienst oder dieselben Administratorzugänge verwendet wie die primäre Infrastruktur, besteht ein gemeinsamer Ausfall- oder Kompromittierungsbereich.

Deshalb sollte die Organisation prüfen, ob für den Notfall eigenständige lokale Benutzerkonten, separate Verwaltungszugänge und alternative Netzwerkwege benötigt werden.

Auch Endgeräte und Serverstandort müssen berücksichtigt werden.

Geeignet für: Unternehmen, Behörden und Organisationen, die einen eigenen Kommunikationsserver als sekundäre Plattform für Krisen- und Incident-Response-Teams betreiben möchten.

Grenzen: Die notwendige Unabhängigkeit muss bei der Bereitstellung hergestellt werden. TrueConf Server Free benötigt zudem eine Verbindung zur Lizenzprüfung und ist nicht für einen dauerhaft isolierten Betrieb vorgesehen.

2. Mattermost: Out-of-Band-Zusammenarbeit für Incident Response

Mattermost ist eine Plattform für sichere Teamkommunikation und Zusammenarbeit. Der Anbieter dokumentiert ausdrücklich Bereitstellungsmodelle für Out-of-Band Incident Response.

Eine separate Mattermost-Umgebung kann außerhalb der primären Unternehmensinfrastruktur betrieben und für Krisenstäbe, IT-Teams und Sicherheitsverantwortliche vorbereitet werden.

Wie funktioniert der OOB-Einsatz?

Die Organisation richtet eine eigenständige Mattermost-Instanz ein, bevor ein Vorfall eintritt.

Die beteiligten Personen erhalten vorbereitete Zugänge. Sicherheitsverantwortliche können darüber Vorfälle besprechen, Aufgaben koordinieren und Informationen austauschen.

Mattermost beschreibt entsprechende Architekturen für eigene Rechenzentren sowie verschiedene Cloud-Umgebungen.

Ein besonderer Schwerpunkt liegt auf der Verbindung von Kommunikation und operativen Incident-Response-Abläufen.

Was muss geprüft werden?

Auch bei Mattermost kommt es auf die tatsächlichen technischen Abhängigkeiten an.

Eine OOB-Instanz darf für die vorgesehenen Ausfallszenarien nicht ausschließlich von derselben Identitätsplattform oder Netzwerkumgebung abhängen wie das Primärsystem.

Darüber hinaus sollten Hosting, verfügbare Funktionen, Lizenzen und Zugriffsrichtlinien vorab geprüft werden.

Geeignet für: Sicherheitsteams, SOCs und größere Organisationen, die eine eigenständige Kommunikations- und Arbeitsumgebung für Sicherheitsvorfälle benötigen.

Grenzen: Die Installation allein gewährleistet keine Ausfallsicherheit. Identität, Zugriffe, Netzwerk und Betrieb müssen unabhängig geplant werden.

3. Element / Matrix: Dezentrale Kommunikation für Krisenteams

Element ist ein Messenger auf Basis des offenen Matrix-Protokolls.

Matrix unterstützt die Kommunikation zwischen unabhängig betriebenen Servern. Element kann daher in Umgebungen eingesetzt werden, in denen Organisationen ihre Messaging-Infrastruktur selbst kontrollieren möchten.

Der Anbieter positioniert Element ausdrücklich auch für Out-of-Band-Kommunikation und Incident Response.

Wie funktioniert der OOB-Einsatz?

Ein Unternehmen kann eine Matrix-Umgebung auf separaten Servern bereitstellen und den Zugriff auf bestimmte Benutzergruppen beschränken.

Die Umgebung kann beispielsweise für Sicherheitsteams und Führungskräfte vorgesehen werden, die während eines Vorfalls vertraulich kommunizieren müssen.

Bei entsprechender Konfiguration können auch voneinander unabhängige Organisationen über föderierte Matrix-Server kommunizieren.

Element unterstützt verschlüsselte Unterhaltungen und verschiedene Bereitstellungsmodelle.

Was muss geprüft werden?

Die Föderation ist nicht automatisch für jeden OOB-Anwendungsfall sinnvoll.

Wenn bei einem Incident besonders vertrauliche Informationen ausgetauscht werden, muss kontrolliert werden, welche externen Server an Räumen beteiligt sind und wo Daten gespeichert werden.

Auch die Authentifizierung muss unabhängig von der gefährdeten Primärumgebung funktionieren.

Geeignet für: Organisationen, die offene Standards, kontrollierbare Server und gegebenenfalls die Zusammenarbeit zwischen mehreren unabhängigen Einrichtungen benötigen.

Grenzen: Der Betrieb einer eigenen Matrix-Infrastruktur und die sichere Konfiguration von Föderation, Berechtigungen und Datenaufbewahrung erfordern entsprechende Fachkenntnisse.

4. Rocket.Chat: Alternativer selbst gehosteter Team-Messenger

Rocket.Chat ist eine Plattform für Messaging, Channels und Zusammenarbeit, die auf eigener Infrastruktur betrieben werden kann.

Für OOB-Szenarien kann eine separate Installation als Ausweichumgebung für bestimmte Teams dienen.

Wie funktioniert der OOB-Einsatz?

Ein Unternehmen betreibt Rocket.Chat zusätzlich zu seiner regulären Kommunikationsplattform.

Im Störungsfall wechseln berechtigte Mitarbeiter auf vorbereitete Channels, um technische Maßnahmen, interne Informationen und Entscheidungen zu koordinieren.

Der selbst gehostete Ansatz ermöglicht es, Server und Netzwerkzugriff getrennt vom primären Cloud-Dienst zu konfigurieren.

Was muss geprüft werden?

Ob Rocket.Chat für ein bestimmtes OOB-Szenario geeignet ist, hängt von der verwendeten Edition, den Anforderungen an die Netzwerkverbindung und den unterstützten Funktionen ab.

Für vollständig isolierte Umgebungen müssen die entsprechenden kommerziellen Optionen und Lizenzbedingungen geprüft werden.

Auch unabhängige Benutzerkonten und Administrationsrechte sind erforderlich, wenn die primäre Identitätsinfrastruktur als mögliches Angriffsziel betrachtet wird.

Geeignet für: Unternehmen, die einen separaten Messenger für Krisenkommunikation und technische Zusammenarbeit bereitstellen möchten.

Grenzen: Eine gewöhnliche zusätzliche Rocket.Chat-Installation erfüllt nicht automatisch alle Anforderungen einer unabhängigen Notfallplattform.

5. Signal: Verschlüsselte Kommunikation als alternativer Kanal

Signal ist ein Messenger mit standardmäßiger Ende-zu-Ende-Verschlüsselung für Nachrichten und Anrufe.

Die Anwendung kann als zusätzlicher Kommunikationsweg verwendet werden, wenn die reguläre Unternehmenskommunikation nicht erreichbar ist.

Wie funktioniert der OOB-Einsatz?

Ein kleines Incident-Response-Team kann vorab eine Signal-Gruppe einrichten.

Wenn die interne Messaging-Plattform ausfällt, können die Mitglieder über ihre Mobilgeräte weiterhin kommunizieren, sofern Internetverbindung, Geräte und Signal-Dienst verfügbar sind.

Dies kann insbesondere dann hilfreich sein, wenn der Angriff hauptsächlich die unternehmenseigene IT betrifft.

Was muss geprüft werden?

Signal ist kein dediziertes Unternehmenssystem für zentrale Notfallverwaltung.

Die Organisation muss festlegen, wer zur Gruppe gehört, wie Mitarbeiterwechsel berücksichtigt werden und welche Informationen über private oder geschäftliche Mobilgeräte ausgetauscht werden dürfen.

Außerdem darf eine externe Messenger-App nicht als vollständig unabhängiger Kommunikationsweg betrachtet werden, wenn dieselbe ausgefallene Internetverbindung benötigt wird.

Geeignet für: kleine Krisenteams, die einen schnell erreichbaren verschlüsselten Zusatzkanal benötigen.

Grenzen: Eingeschränkte zentrale Administration und Abhängigkeit von Endgeräten, Internetzugang und externem Dienst.

6. Telefonie, Mobilfunk und Satellitenkommunikation

Out-of-Band-Kommunikation muss nicht ausschließlich über Messenger erfolgen.

Telefonische Krisenkommunikation, unabhängige Mobilfunkverbindungen und satellitengestützte Systeme können eine wichtige Ergänzung bilden.

Insbesondere bei größeren Netzwerkstörungen kann ein alternativer Übertragungsweg entscheidender sein als die Wahl einer weiteren Chat-Anwendung.

Wie funktioniert der OOB-Einsatz?

Eine Organisation erstellt vorab eine Liste kritischer Kontaktpersonen mit alternativen Telefonnummern.

Für Standorte mit besonderen Verfügbarkeitsanforderungen können zusätzliche Mobilfunkanbieter oder geeignete Satellitenkommunikationssysteme vorgesehen werden.

Dadurch besteht die Möglichkeit, auch dann Kontakt zu halten, wenn die reguläre Unternehmensnetzverbindung nicht verfügbar ist.

Was muss geprüft werden?

Unabhängige Leitungen oder Anbieter sind nur dann hilfreich, wenn sie nicht denselben relevanten Ausfallpunkt besitzen.

Beispielsweise können mehrere Mobilfunkverträge eine gemeinsame regionale Störung nicht zwangsläufig überstehen.

Für besonders kritische Kommunikationswege sind deshalb Stromversorgung, Netzabdeckung, Geräteverfügbarkeit und regelmäßige Funktionstests wichtig.

Geeignet für: Krisenstäbe, kritische Infrastrukturen, verteilte Standorte und Organisationen mit Anforderungen an zusätzliche Netzunabhängigkeit.

Grenzen: Begrenzte Möglichkeiten für Team-Chats, Dateiaustausch und die strukturierte Dokumentation von Incident-Response-Abläufen.

Warum ein zweiter Messenger noch keine OOB-Lösung ist

Einer der häufigsten Planungsfehler besteht darin, lediglich eine zusätzliche Kommunikationsanwendung zu installieren.

Zwei voneinander unabhängige Programme können dieselben kritischen Komponenten verwenden.

Ein Unternehmen nutzt beispielsweise Microsoft Teams als primären Messenger und eine zweite Anwendung als Backup. Beide greifen jedoch auf denselben Unternehmens-SSO zu.

Wird dieser Identitätsdienst kompromittiert oder abgeschaltet, verlieren Mitarbeiter möglicherweise gleichzeitig den Zugang zu beiden Systemen.

Dasselbe Problem entsteht, wenn beide Kommunikationsplattformen ausschließlich über ein gemeinsames VPN erreichbar sind, das im Störungsfall ausfällt.

Fünf gemeinsame Abhängigkeiten

Abhängigkeit	Mögliche Folge	OOB-Maßnahme
Gemeinsamer Identitätsanbieter	Beide Systeme können nicht mehr authentifizieren	Unabhängige Notfallkonten
Gleiches Netzwerk oder VPN	Ausfall macht beide Plattformen unerreichbar	Alternativer Netzwerkzugang
Gleiche Cloud-Umgebung	Störung kann beide Systeme betreffen	Separater Hosting-Bereich oder Betreiber
Gemeinsame Administratorzugänge	Angreifer könnten beide Umgebungen kontrollieren	Getrennte privilegierte Konten
Dieselben kompromittierten Endgeräte	Vertrauliche Kommunikation bleibt gefährdet	Vorbereitete vertrauenswürdige Ersatzgeräte

Nicht jede Organisation benötigt in jedem Bereich eine vollständige physische Trennung.

Entscheidend ist, welche konkreten Ereignisse die OOB-Umgebung überstehen soll.

Eine Plattform für den Ausfall eines Cloud-Dienstes kann andere Anforderungen haben als eine Umgebung für die Koordination während einer vollständigen Kompromittierung der Unternehmensdomäne.

Out-of-Band-Kommunikation und Out-of-Band-Management

Beide Begriffe beruhen auf dem gleichen Prinzip: Ein alternativer Weg soll unabhängig von der normalen Betriebsinfrastruktur verfügbar bleiben.

Sie dienen jedoch unterschiedlichen Zwecken.

Out-of-Band-Kommunikation verbindet Menschen. IT-Teams, Krisenstäbe und Führungskräfte können damit Informationen austauschen und Entscheidungen treffen.

Out-of-Band-Management ermöglicht Administratoren den Zugriff auf technische Systeme über ein separates Verwaltungsnetz. Dazu gehören beispielsweise Router, Switches, Serverkonsolen und andere Infrastrukturkomponenten.

Merkmal	OOB-Kommunikation	OOB-Management
Ziel	Zusammenarbeit während eines Vorfalls	Zugriff und Wiederherstellung technischer Systeme
Benutzer	Krisenstab, IT, Security, Management	Netzwerk- und Systemadministratoren
Typische Technik	Messenger, Sprachdienste, Notfallkommunikation	Management-Ports, Konsolenserver, getrennte Netze
Hauptaufgabe	Entscheidungen und Koordination	Diagnose, Konfiguration und Wiederherstellung

Bei schweren IT-Vorfällen können beide Bereiche notwendig sein.

Administratoren benötigen technische Zugänge zur Wiederherstellung, während die beteiligten Personen unabhängig voneinander Informationen austauschen können müssen.

So richten Unternehmen sichere OOB-Kommunikation ein

Eine OOB-Umgebung sollte nicht erst während eines Angriffs installiert werden.

Wenn die Organisation bereits von einem Sicherheitsvorfall betroffen ist, können Administratorzugänge, Arbeitsstationen und interne Kommunikationswege nicht mehr vertrauenswürdig sein.

Ein vorbereiteter Plan ist deshalb entscheidend.

Schritt 1. Kritische Ausfallszenarien definieren

Zunächst sollte festgelegt werden, welche Ereignisse der alternative Kommunikationskanal überstehen muss.

Typische Beispiele sind ein Cloud-Ausfall, ein Ransomware-Angriff, die Kompromittierung des Identitätsanbieters oder eine Unterbrechung des Internetzugangs.

Die Risiken müssen möglichst konkret beschrieben werden.

Schritt 2. Gemeinsame Abhängigkeiten prüfen

Erstellen Sie eine Übersicht der benötigten Systeme.

Dazu gehören Hosting, Authentifizierung, Netzwerk, Endgeräte, Administratorzugänge und externe Dienste.

Prüfen Sie anschließend, welche dieser Komponenten auch vom primären Kommunikationssystem verwendet werden.

Je größer die Überschneidung, desto höher ist das Risiko eines gemeinsamen Ausfalls.

Schritt 3. Plattform und Übertragungswege auswählen

Die Wahl hängt davon ab, ob hauptsächlich Nachrichten, Sprachgespräche, Videokonferenzen oder strukturierte Incident-Response-Abläufe benötigt werden.

Für eine vollständig kontrollierte zweite Kommunikationsumgebung können selbst gehostete Plattformen wie TrueConf Server oder Mattermost geprüft werden.

Für bestimmte Teams können verschlüsselte externe Messenger oder zusätzliche Telefonieverbindungen eine sinnvolle Ergänzung sein.

Schritt 4. Zugriffe vor dem Vorfall vorbereiten

Alle erforderlichen Personen müssen rechtzeitig Zugang erhalten.

Dazu gehören nicht nur IT- und Sicherheitsteams, sondern gegebenenfalls auch Geschäftsführung, Datenschutz, Rechtsabteilung und externe Spezialisten.

Alternative Zugangsdaten und Kontaktinformationen müssen sicher verfügbar sein, ohne auf kompromittierte Unternehmenssysteme angewiesen zu sein.

Schritt 5. Regeln für vertrauliche Informationen festlegen

Im OOB-Kanal können besonders sensible Informationen ausgetauscht werden, etwa technische Angriffsdaten, Zugangsinformationen oder Entscheidungen zur Abschaltung von Systemen.

Es sollte deshalb vorab geklärt werden, welche Informationen geteilt werden dürfen und wer Zugriff auf bestimmte Unterhaltungen erhält.

Auch die Speicherung und spätere Übernahme der Incident-Dokumentation sind wichtig.

Schritt 6. Regelmäßig testen

Eine OOB-Plattform kann technisch funktionieren und trotzdem im Ernstfall unbrauchbar sein.

Beispielsweise kennen Mitarbeiter ihre Notfallzugangsdaten nicht mehr oder die vorbereiteten Geräte wurden seit Monaten nicht aktualisiert.

Testen Sie deshalb gezielt den Ausfall der primären Authentifizierung, der Kommunikationsplattform und gegebenenfalls des Netzwerks.

Ein erfolgreicher Test sollte zeigen, dass das Krisenteam die alternative Umgebung ohne Rückgriff auf das gestörte Primärsystem erreichen kann.

Beispiel: OOB-Kommunikation bei einem Ransomware-Angriff

Ein mittelständisches Unternehmen nutzt Microsoft 365, Active Directory und einen internen Messenger.

An einem Montagmorgen meldet das Sicherheitsteam verdächtige Anmeldungen. Gleichzeitig lassen sich mehrere Systeme nicht mehr erreichen.

Die IT vermutet, dass die Unternehmensdomäne kompromittiert wurde.

Ohne vorbereitete OOB-Kommunikation müsste das Team möglicherweise dieselben E-Mail-Konten oder Messenger verwenden, über die Angreifer bereits Zugriff erlangt haben könnten.

Mit vorbereiteter OOB-Umgebung kann das Unternehmen einen definierten Notfallprozess aktivieren.

Die Beteiligten wechseln auf eine separate Kommunikationsplattform mit unabhängigen Zugängen. Dort stimmen sie die Untersuchung, die Isolierung betroffener Systeme und die Kommunikation mit externen Fachleuten ab.

Wurde beispielsweise TrueConf Server als separate OOB-Komponente eingerichtet, kann das Incident-Team Chats und Videokonferenzen verwenden, solange Server, Zugang und Netzwerk vom Vorfall nicht betroffen sind.

Für den Fall eines umfassenden Netzwerkausfalls können zusätzliche Telefonverbindungen oder andere unabhängige Kommunikationswege erforderlich sein.

Das Beispiel zeigt: Die entscheidende Eigenschaft einer OOB-Lösung ist nicht eine bestimmte Softwarefunktion, sondern ihre Verfügbarkeit außerhalb des betroffenen Ausfallbereichs.

Checkliste: Ist Ihre OOB-Kommunikation wirklich unabhängig?

Prüffrage	Ziel
Kann sich das Krisenteam ohne das primäre SSO anmelden?	Unabhängige Authentifizierung
Ist die Plattform ohne den normalen Messenger erreichbar?	Getrennter Dienst
Funktioniert der Zugang bei einem Ausfall des Unternehmens-VPN?	Alternative Netzwerkverbindung
Sind Administratorzugänge getrennt?	Schutz vor gemeinsamer Kompromittierung
Sind alternative Endgeräte vorbereitet?	Zugriff bei kompromittierten Arbeitsstationen
Können externe Incident-Response-Partner teilnehmen?	Zusammenarbeit im Krisenfall
Sind Kontaktlisten außerhalb der Primärsysteme verfügbar?	Erreichbarkeit ohne Unternehmens-E-Mail
Gibt es Regeln für vertrauliche Daten und Aufzeichnungen?	Kontrollierte Informationsverarbeitung
Wurde ein realistischer Ausfall getestet?	Nachgewiesene Einsatzfähigkeit

Je nach Einsatzszenario können weitere Anforderungen notwendig sein, beispielsweise alternative Stromversorgung, zusätzliche Netzbetreiber oder ein getrenntes Verwaltungsnetz.

Häufig gestellte Fragen zur Out-of-Band-Kommunikation

Was bedeutet Out-of-Band-Kommunikation?

Out-of-Band-Kommunikation ist ein alternativer Kommunikationsweg, der bei einem Ausfall oder einer Kompromittierung der regulären Unternehmenssysteme genutzt wird. Ziel ist es, kritische Informationen und Entscheidungen weiterhin sicher austauschen zu können. Dazu können separate Messenger, Telefonverbindungen oder eigenständig betriebene Kommunikationsserver gehören.

Wann benötigt ein Unternehmen OOB-Kommunikation?

Out-of-Band-Kommunikation ist besonders bei Ransomware-Angriffen, kompromittierten Identitätsdiensten, Ausfällen von Cloud-Plattformen und größeren Netzwerkstörungen relevant. Unternehmen sollten eine alternative Kommunikationsumgebung vorbereiten, bevor ein entsprechender Vorfall eintritt.

Ist ein zweiter Messenger automatisch eine Out-of-Band-Lösung?

Nein. Zwei Messenger können denselben Identitätsanbieter, dieselben Administratorzugänge oder dieselbe Netzwerkinfrastruktur verwenden. Eine echte OOB-Lösung muss ausreichend unabhängig von den Komponenten sein, deren Ausfall oder Kompromittierung sie überstehen soll.

Kann TrueConf Server für Out-of-Band-Kommunikation eingesetzt werden?

Ja. TrueConf Server kann als separat betriebene Kommunikationsumgebung für Chats, Sprach- und Videoanrufe sowie Videokonferenzen eingesetzt werden. Entscheidend ist eine Architektur mit geeigneter Trennung von primärer Authentifizierung, Netzwerkinfrastruktur und Administration. Die Vollversion kann auch innerhalb isolierter Unternehmensnetze betrieben werden.

Was ist der Unterschied zwischen OOB-Kommunikation und OOB-Management?

OOB-Kommunikation stellt einen unabhängigen Kanal für die Zusammenarbeit von Menschen bereit. OOB-Management ermöglicht dagegen Administratoren, technische Systeme über separate Verwaltungsverbindungen zu erreichen. Bei größeren IT-Vorfällen können beide Maßnahmen notwendig sein.

Kann Out-of-Band-Kommunikation ohne Internet funktionieren?

Ja, sofern die verwendete Plattform und die Übertragungswege dafür ausgelegt sind. Ein lokal betriebener Kommunikationsserver kann innerhalb eines erreichbaren Unternehmensnetzes funktionieren. Für standortübergreifende Kommunikation bei einem umfassenden Netzausfall können jedoch zusätzliche unabhängige Verbindungen erforderlich sein.

Fazit: Out-of-Band-Kommunikation muss unabhängig funktionieren

Out-of-Band-Kommunikation stellt sicher, dass eine Organisation während eines Cyberangriffs, Cloud-Ausfalls oder einer größeren IT-Störung weiterhin handlungsfähig bleiben kann.

Plattformen wie TrueConf Server, Mattermost, Element und Rocket.Chat können als Basis einer separaten Kommunikationsumgebung dienen. Ergänzend kommen verschlüsselte Messenger sowie unabhängige Telefonie- und Netzwerkverbindungen infrage.

Eine zweite Anwendung allein genügt jedoch nicht. Entscheidend ist die Trennung kritischer Abhängigkeiten: Identität, Hosting, Netzwerkanbindung, Administratorrechte und Endgeräte.

Eine wirksame OOB-Lösung ist deshalb kein gewöhnliches Backup-Tool, sondern ein vorab getesteter Kommunikationsweg, der auch dann funktioniert, wenn das primäre System nicht mehr erreichbar oder vertrauenswürdig ist.