Mobile-Menu

Wer UCC nur als Meeting-Tool absichert, unterschätzt das Risiko Unified Communication gehört heute zur kritischen Infrastruktur

Ein Gastbeitrag von Dawson Cai 5 min Lesedauer

Anbieter zum Thema

Yealink (Xiamen) Network Technology CO., Ltd
FTAPI Software GmbH

Unified Communications & Collaboration (UCC) hat sich vom Meeting-Tool zum Fundament moderner Unternehmen entwickelt, doch die Sicherheit hinkt hinterher. Zuständigkeitslücken zwischen Collaboration-, Security- und Einkaufsteams verhindern einen durchgängigen Schutz. Gefährlich sind dabei selten Zero-Days, sondern Fehlkonfigurationen, fragile Update-Ketten und fehlendes Lifecycle-Denken.

UCC hat sich vom Meeting-Tool zur kritischen Infrastruktur entwickelt. Sicherheit muss deshalb über den gesamten Lebenszyklus gedacht werden, nicht als nachträgliches Add-on.(Bild: © zorandim75 - stock.adobe.com)
UCC hat sich vom Meeting-Tool zur kritischen Infrastruktur entwickelt. Sicherheit muss deshalb über den gesamten Lebenszyklus gedacht werden, nicht als nachträgliches Add-on.
(Bild: © zorandim75 - stock.adobe.com)

Unified Communications & Collaboration (UCC) hat ihre Rolle in Unternehmen still und leise verändert. Was früher vor allem „Meeting-Tools“ waren, ist heute das Fundament dafür, wie Entscheidungen getroffen werden, wie der Betrieb läuft und wie Organisationen in hybriden Arbeitsmodellen produktiv bleiben. Das hat eine direkte Sicherheitsfolge: UCC ist keine periphere IT-Anwendung mehr. Sie ist fester Bestandteil der Unternehmensstruktur – und sollte entsprechend kritisch abgesichert werden – mit denselben Maßstäben wie andere geschäftskritische Systeme.

Und doch fällt UCC-Security in vielen Organisationen durch die Zuständigkeitslücken. Collaboration-Teams konzentrieren sich auf User Experience und Verfügbarkeit; Security-Teams auf Identity, Endpoints und Cloud Controls; der Einkauf auf Zertifizierungen und den Preis. Das Ergebnis ist vorhersehbar: Sicherheitsmaßnahmen werden erst nachträglich ergänzt, und Resilienz hängt dann von Konfigurationsdisziplin und reaktivem Patchen ab.

Von „Features“ hin zu Entwicklungsprinzipien

In der Security-Community sehen wir zunehmend: Die folgenschwersten Ausfälle sind nicht exotische Zero-Days, sondern Schwächen, die aus Design- und Implementierungs­ent­schei­dung­en entstehen – Fehlkonfigurationen, kryptografische Fehler, fragile Update-Ketten und uneinheitliche Policy Enforcement über heterogene Device-Fleets hinweg.

Genau deshalb ist „Secure by Design“ mehr als ein Slogan. Es ist eine Engineering-Maxime: Sie gehen davon aus, dass das Produkt angegriffen wird, und entwerfen das System dann so, dass eine Kompromittierung schwierig ist, erkannt wird und begrenzt bleibt.

Der praktischste Weg, das Realität werden zu lassen, ist, Sicherheit als kontinuierliche Kette zu behandeln – nicht als Checkliste. Diese Kette beginnt mit der ersten Instruktion des Geräts und reicht über Firmware-Updates, Identity, Management und Decommissioning. Reißt ein Glied, verliert der Rest der Architektur erheblich an Wert.

Wie „Security by Design“ auf Endpoints aussieht

Für UCC-Endpoints wie IP-Telefone und Meeting Devices ist das grundlegende Thema Vertrauen: Kann die Organisation darauf vertrauen, dass beim Booten das startet, was beabsichtigt war – und dass das, was läuft, intakt bleibt?

In der Praxis heißt das auf Integrität und Least Privilege hin zu entwickeln. Secure Boot und Verified Boot Chains reduzieren das Risiko, dass beim Start nicht autorisierter Code ausgeführt wird. Firmware-Integritätsprüfungen und digitale Signaturen helfen sicherzustellen, dass Update-Pakete authentisch und nicht manipuliert sind. Der Schutz sensibler Keys in hardware-gestützten Umgebungen (zum Beispiel über Trusted-Execution-Mechanismen) begrenzt den Blast Radius, falls andere Teile des Systems kompromittiert werden. Und verschlüsselte Kommunikation – TLS für Signaling, SRTP für Media – sollte Normalbetrieb sein, kein Sondermodus.

Diese Maßnahmen sind keine „zusätzlichen Security-Features“. Sie sind die Baseline, die alles andere erst ermöglicht: sicheres Remote Management, verlässliche Incident Response und Vertrauen in Lifecycle Updates.

Die Supply Chain ist Teil des Threat Models

UCC-Security hängt auch davon ab, wo Komponenten herkommen, wie sie zusammengebaut werden und wie die Software-Supply-Chain des Geräts kontrolliert wird. Deutsche Käufer fordern berechtigterweise Transparenz: Wer baut was? Welche Zulieferer sind beteiligt? Wie werden Änderungen validiert? Welche Test- und Factory-Kontrollmechanismen existieren?

Organisationen sollten Anbieter zu Traceability, Component Provenance und sicheren Fertigungsprozessen verpflichten – nicht als Papierübung, sondern zur Risikoreduktion. Eine vertrauenswürdige Supply Chain ist unsichtbar, wenn sie funktioniert, und schmerzhaft sichtbar, wenn sie es nicht tut.

Plattform-Ökosysteme: Security-Reife durch Governance

UCC-Endpoints arbeiten selten allein; sie leben in Ökosystemen wie Microsoft Teams oder Zoom. Bei der Plattformzertifizierung geht es deshalb nicht nur um Interoperabilität. Sie ist oft ein Proxy dafür, ob ein Gerät mit sich weiterentwickelnden Sicherheitsanforderungen Schritt halten kann: Identity Integration, Conditional Access, Policy Enforcement und Lifecycle Governance.

Aus unserer Erfahrung führt eine langfristige Engineering-Kollaboration mit diesen Plattformen zu besseren Security Outcomes als isolierte Point Solutions. Anforderungen entwickeln sich weiter, Threat Models reifen, und Integrationsmuster verbessern sich. Je tiefer Endpoints an Identity und Management auf Plattformebene teilnehmen können, desto konsistenter können Unternehmen Policies durchsetzen – insbesondere über große Flotten und verteilte Belegschaften hinweg.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Am deutlichsten sehen wir das im Microsoft-Teams-Device-Ökosystem: Langfristige Zusammenarbeit übersetzt sich tendenziell in klarere Security-„Rules of the Road“ für Identity, Policy und Lifecycle Management. Im Rahmen unserer laufenden Unterstützung für Microsofts Device Ecosystem Platform (MDEP) sorgen wir dafür, dass Device Identity und Policy Enforcement in der Fläche konsistenter zu machen – ein operativer Bedarf für IT-Teams, die große Flotten managen, nicht ein Feature für eine Broschüre.

Privacy und Compliance: Design für „wo“ und „wer“

UCC ist auch ein Data-Governance-Problem. Metadaten und Device Telemetry werfen Fragen auf, die operativ und rechtlich sind: wo Daten gespeichert werden, wer darauf zugreifen kann, wie lange sie aufbewahrt werden und wie grenzüberschreitende Transfers gehandhabt werden. Für deutsche Organisationen ist das nicht abstrakt – es ist tägliche Procurement Reality.

Ein sinnvoller Ansatz ist „Privacy & Compliance by Design“: Produkte und Services so zu bauen, dass Verschlüsselung, Access Control, Auditing und regionale Deployment-Optionen von Anfang an in der Architektur verankert sind.

Aus Kundensicht geht die Bewertung von Compliance über das Prüfen von Policy Statements hinaus. Unternehmen sollten nach verifizierbaren, operativen Nachweisen suchen, dass Privacy- und Security-Kontrollen konsistent implementiert sind – etwa durch klare und transparente Dokumentation (zum Beispiel über ein Trust Center), anerkannte Zertifizierungen wie ISO 27001 oder SOC 2, wo anwendbar, sowie reife operative Prozesse für Vulnerability Management, unabhängige Security Tests und Incident Response.

Eine realistischere Baseline für UCC

UCC hat eine Stufe erreicht, in der Sicherheit kein Add-on mehr ist, sondern eine strukturelle Anforderung. Die verantwortungsvollste Haltung ist, Kompromittierungsversuche als gegeben anzunehmen und Systeme so zu entwickeln, dass sie Auswirkungen minimieren, Integrität bewahren und schnelle Recovery unterstützen.

Für Anbieter heißt das, Secure-Design-Prinzipien als produktseitige Grundlagen zu behandeln. Für Enterprise Buyer bedeutet es, UCC wie kritische Infrastruktur zu bewerten: Architektur, Supply Chain, Platform Governance und Compliance – gemeinsam, nicht getrennt. Wenn wir uns auf diesen Grundkonsens verständigen, heben wir das Sicherheitsniveau für das gesamte Collaboration-Ökosystem.

Über den Autor: Dawson Cai ist Vice President Product bei Yealink und verantwortet die Gerätestrategie sowie die Engineering-Planung für führende Kollaborationsplattformen wie Microsoft Teams und Zoom. Er ist seit 2007 bei Yealink und verfügt über mehr als 18 Jahre Erfahrung im Bereich UCC. Seine Schwerpunkte liegen auf „Secure-by-Design“-Architekturen, Plattformkompatibilität, großflächigen Rollouts und langfristiger Governance.

(ID:50822102)

Weiterführende Inhalte