Android-Anrufererkennung: Was IT-Verantwortliche jetzt wissen müssen
Gefälschte Anrufer-IDs als unterschätztes Unternehmensrisiko
Betrugsanrufe mit gefälschten Absenderidentitäten sind längst kein reines Verbraucherproblem mehr. In deutschen Unternehmen gehören sogenannte Spoofing-Angriffe – bei denen Angreifer die angezeigte Rufnummer manipulieren – zu den wachsenden Einfallstoren für Social Engineering, CEO-Fraud und Datenschutzverletzungen. Google hat nun reagiert und kündigt für Android einen neuen Mechanismus zur verifizierten Anrufererkennung an. Was steckt dahinter, welche Relevanz hat das für die betriebliche IT-Sicherheit – und was müssen IT-Verantwortliche und Geschäftsführer konkret tun?
Technischer Hintergrund: Wie funktioniert die neue Android-Anrufererkennung?
Googles neuer Ansatz zur Anrufererkennung zielt darauf ab, die Echtheit einer angezeigten Rufnummer kryptografisch zu verifizieren. Konkret bedeutet das: Anrufer – insbesondere Unternehmen und Behörden – können ihre Identität gegenüber dem Android-System vorab hinterlegen oder über einen signierten Datensatz bestätigen lassen. Das Endgerät gleicht den eingehenden Anruf mit diesen Vertrauensankern ab und signalisiert dem Nutzer visuell, ob die Identität des Anrufers als verifiziert gilt.
Der Mechanismus greift dabei auf bereits bekannte Standards zurück, die im VoIP-Umfeld unter dem Begriff STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs) etabliert sind. Diese in den USA bereits verpflichtend eingeführten Protokolle fügen einem Anruf eine digitale Signatur bei, die von Netzbetreibern und Endgeräten ausgewertet werden kann.
Für Android bedeutet das praktisch:
- Grünes Häkchen oder Verifizierungssymbol bei bestätigten Anrufern
- Warnhinweis bei verdächtigen oder nicht verifizierbaren Nummern
- Integration in bestehende Spam-Erkennungsmechanismen von Google
Wichtig für IT-Verantwortliche: Die Schutzwirkung ist abhängig von der Unterstützung seitens der Netzbetreiber. In Deutschland sind STIR/SHAKEN-äquivalente Standards noch nicht flächendeckend verpflichtend – die Telekom, Vodafone und Telefónica befinden sich jedoch in entsprechenden Pilotprojekten.
Relevanz für Deutschland: NIS2, BSI und die Pflicht zur Resilienz
NIS2 und Social Engineering als Angriffsvektor
Die NIS2-Richtlinie (Richtlinie EU 2022/2555), die in Deutschland durch die Novellierung des BSI-Gesetzes (BSIG) in nationales Recht überführt wird, verpflichtet betroffene Einrichtungen explizit zur Implementierung geeigneter technischer und organisatorischer Maßnahmen (TOM). Telefonbasierte Angriffe – insbesondere Vishing (Voice Phishing) und CEO-Fraud – fallen unter die Angriffsvektoren, gegen die Unternehmen Schutzmaßnahmen nachweisen müssen.
Konkret relevant sind folgende NIS2-Anforderungen:
| NIS2-Anforderung | Bezug zu Anrufer-Spoofing |
|---|---|
| Art. 21 Abs. 2 lit. a – Risikoanalyse und Sicherheitskonzepte | Spoofing-Risiken müssen bewertet und dokumentiert sein |
| Art. 21 Abs. 2 lit. b – Vorfallbewältigung | CEO-Fraud-Anrufe können meldepflichtige Vorfälle auslösen |
| Art. 21 Abs. 2 lit. g – Grundlegende Cyberhygiene | Sensibilisierung der Mitarbeiter für Vishing-Angriffe |
| Art. 21 Abs. 2 lit. i – Sicherheit der Kommunikation | Technische Maßnahmen gegen Rufnummernmanipulation |
BSI-Empfehlungen und aktuelle Warnungen
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt regelmäßig vor Telefonbetrug durch gefälschte Behörden- oder Unternehmensnummern. Im BSI-Grundschutz-Kompendium (insbesondere Baustein ORP.3 – Sensibilisierung und Schulung) wird explizit auf Social-Engineering-Risiken über Telefonkanäle hingewiesen. Unternehmen, die unter NIS2 fallen, sind gut beraten, Spoofing-Schutz als dokumentierten Bestandteil ihres Sicherheitskonzepts aufzunehmen.
5 konkrete Schutzmaßnahmen für Unternehmen
1. Rückrufpflicht als verbindliche Prozessregel einführen
Definieren Sie interne Richtlinien, nach denen sensible Aktionen – etwa Überweisungen, Zugangsdaten-Weitergaben oder Vertragsänderungen – niemals aufgrund eines eingehenden Anrufs allein ausgeführt werden. Mitarbeiter müssen verpflichtend über eine verifizierte, bekannte Nummer zurückrufen – nicht über die angezeigte Rufnummer des Anrufers.
2. Mobile Device Management (MDM) zur Steuerung von Android-Updates nutzen
Stellen Sie sicher, dass alle dienstlich genutzten Android-Geräte zeitnah Sicherheitsupdates erhalten und neue Sicherheitsfunktionen – wie die neue Anrufererkennung – tatsächlich aktiviert sind. Über eine MDM-Lösung (z. B. Microsoft Intune, VMware Workspace ONE) lässt sich der Update-Stand zentral überwachen und erzwingen.
3. Mitarbeiterschulungen um Vishing-Szenarien erweitern
Klassische Phishing-Awareness-Trainings decken E-Mail-basierte Angriffe ab – Vishing (Voice Phishing) wird dabei häufig vernachlässigt. Ergänzen Sie Ihre Schulungsprogramme um realistische Telefonszenarien: Wie reagiere ich, wenn jemand vorgibt, vom IT-Helpdesk, der Geschäftsführung oder einer Behörde zu sein?
Praxistipp: Dienste wie KnowBe4 oder der BSI-eigene Rahmen für Awareness-Maßnahmen bieten Vorlagen für Vishing-Simulationen.
4. DECT- und VoIP-Infrastruktur absichern
Überprüfen Sie, ob Ihre interne Telefonanlage (insbesondere bei SIP-basierten VoIP-Lösungen) Rufnummernmanipulationen von außen verhindert. Konfigurieren Sie SIP-Trunk-Einstellungen so, dass externe Anrufer keine internen Durchwahlen als Absendernummer vortäuschen können. Viele Standard-Konfigurationen sind hier leider noch angreifbar.
5. Spoofing-Risiken in die Risikoanalyse aufnehmen und dokumentieren
Gemäß NIS2 und dem BSI IT-Grundschutz müssen identifizierte Risiken dokumentiert, bewertet und mit Maßnahmen hinterlegt sein. Nehmen Sie Telefonbetrug und Spoofing explizit in Ihr Risikoregister auf – einschließlich der Eintrittswahrscheinlichkeit, des potenziellen Schadens (z. B. Finanzbetrug, Datenweitergabe) und der implementierten Gegenmaßnahmen. Das schützt Sie auch im Fall einer BSI-Prüfung oder eines meldepflichtigen Vorfalls.
Exkurs: Was bringt die Android-Funktion wirklich – und was nicht?
Es wäre unrealistisch, Googles neue Anrufererkennung als Allheilmittel darzustellen. Die Funktion ist ein sinnvoller Schritt, aber kein vollständiger Schutz. Folgende Einschränkungen müssen IT-Verantwortliche kennen:
- Netzwerkabhängigkeit: Ohne Unterstützung durch den Mobilfunkbetreiber greift die Verifizierung nicht zuverlässig.
- Geräteheterogenität: In Unternehmen laufen häufig ältere Android-Versionen oder iOS-Geräte – die neue Funktion schützt dort nicht.
- Keine Absicherung von Festnetz oder VoIP: Die Android-Funktion schützt nur eingehende Mobilanrufe auf dem jeweiligen Gerät.
- Kein Schutz vor internem Missbrauch: Wer legitimen Zugang zu einer verifizierten Nummer hat, kann diese dennoch für Betrug nutzen.
Kurz gesagt: Die Maßnahme ergänzt ein Sicherheitskonzept – sie ersetzt es nicht.
Fazit: Technische Neuerungen als Anlass zur strategischen Überprüfung nutzen
Googles neue Anrufererkennung für Android ist ein willkommenes Signal aus der Industrie, dass Telefonbetrug als ernstzunehmende Bedrohung anerkannt wird. Für deutsche IT-Verantwortliche und Geschäftsführer sollte diese Entwicklung als Anlass dienen, die eigene Sicherheitsstrategie rund um den Kommunikationskanal Telefon kritisch zu hinterfragen.
Unter NIS2 sind betroffene Unternehmen ohnehin verpflichtet, Risiken durch Social Engineering – zu dem Vishing zweifellos zählt – systematisch zu adressieren. Wer jetzt handelt, schützt nicht nur sein Unternehmen vor finanziellem Schaden, sondern erfüllt auch dokumentierte Compliance-Anforderungen.
Call-to-Action: NIS2-Compliance strukturiert angehen
Die Anforderungen der NIS2-Richtlinie umfassen weit mehr als technische Einzelmaßnahmen – sie verlangen ein ganzheitliches, dokumentiertes Sicherheitsmanagementsystem. Spezialisierte NIS2-Compliance-Software unterstützt IT-Verantwortliche dabei, Risikoanalysen zu strukturieren, Maßnahmenpläne zu dokumentieren, Meldepflichten zu tracken und Nachweise für Audits bereitzuhalten. Wenn Sie noch kein systematisches Tool im Einsatz haben, lohnt sich ein Vergleich verfügbarer Plattformen – etwa auf Basis der BSI-Anforderungen oder einschlägiger ENISA-Empfehlungen.