# Angriffsfläche

> Die Angriffsfläche eines Systems ist die Menge aller Punkte an seiner Grenze, über die ein Angreifer eindringen, es beeinflussen oder Daten herausholen kann: Netzwerkdienste, Funkschnittstellen, physische Ports, APIs, Update-Kanäle, Lieferanten und Menschen. NIST definiert den Begriff in SP 800-53. Der Cyber Resilience Act verlangt, Produkte so zu gestalten, dass sie begrenzt wird. Die Angriffsfläche zu erfassen ist der erste Schritt jedes Penetrationstests und jeder TARA.

Die Angriffsfläche ist jeder Punkt, den ein Angreifer an einem System erreichen kann: Schnittstellen, Debug-Zugänge, Menschen. Wie du sie erfasst und reduzierst.

Source: https://zyberum.com/de/glossar/angriffsflaeche · Updated: 2026-10-07

## Was ist eine Angriffsfläche?

Die Angriffsfläche ist die Menge aller Punkte an der Grenze eines Systems, an denen ein Angreifer versuchen kann hineinzukommen, eine Wirkung zu erzielen oder Daten herauszuholen. NIST SP 800-53 Rev. 5 definiert sie genau so für ein System, eine Systemkomponente oder eine Umgebung. Einfach gesagt: Jede Schnittstelle, jedes Protokoll, jede Eingabe und jede Person mit Zugang gehört dazu.

Bei einem vernetzten Produkt umfasst die Angriffsfläche typischerweise Netzwerkdienste und offene Ports, Funkschnittstellen (WLAN, BLE, Mobilfunk, proprietäre 2,4-GHz-Funkstrecken), physische Schnittstellen (USB, SD-Karte, UART, JTAG, SWD, zugänglicher Flash-Speicher), die Cloud-API und die Mobile App, den Firmware-Update-Kanal, Drittkomponenten und die Lieferkette sowie die Menschen, die es administrieren oder nutzen. Beim Fahrzeug kommen CAN-, LIN- und Ethernet-Busse, der OBD-Anschluss, Diagnosedienste (UDS, DoIP), Telematik und Ladeschnittstellen dazu.

## Wo ist es definiert?

NIST definiert den Begriff in SP 800-53 Rev. 5, SP 800-160 und SP 800-172. Das Attack Surface Analysis Cheat Sheet von OWASP beschreibt, wie man sie für Anwendungen identifiziert, erfasst und verwaltet: Ein- und Austrittspunkte, Datenflüsse, die wertvollen Assets dahinter und wie Änderungen über die Zeit wirken.

Im EU-Recht macht der Cyber Resilience Act das Konzept zur Produktanforderung: Anhang I Teil I Nummer 2 Buchstabe h verlangt, dass Produkte mit digitalen Elementen so konzipiert, entwickelt und hergestellt werden, dass Angriffsflächen einschließlich externer Schnittstellen begrenzt werden. Im Automotive-Engineering wird die Angriffsfläche in der Item Definition und der Angriffspfadanalyse einer TARA nach ISO/SAE 21434 erfasst, und IEC 62443 behandelt sie für Industriesysteme, indem sie diese in Zonen teilt und die Conduits dazwischen begrenzt.

## Was es in der Praxis bedeutet

Die Angriffsfläche zu erfassen ist die erste Woche jedes Hardware- oder Steuergeräte-Penetrationstests bei uns und das erste Arbeitsprodukt jeder TARA. Erst mit vollständiger Liste lassen sich Umfang, Dauer und Tiefe sinnvoll vereinbaren. Die Überraschungen stehen fast immer auf der Liste der Dinge, die niemand als Schnittstelle gesehen hat:

- Ein **UART-Debug-Port** auf der Serienplatine mit Root-Shell und ohne Passwort, bei Haushaltsgeräten genauso wie bei Kommunikationsmodulen.
- **UDS-Dienste**, die in der Default Session ohne Authentifizierung antworten, inklusive Routinen, die nur für die Fertigungslinie gedacht waren.
- **Test- und Staging-Endpunkte**, die in der produktiven Cloud-API ausgeliefert wurden, oder ein MQTT-Broker, der anonyme Verbindungen akzeptiert.
- Ein **Firmware-Update-Mechanismus**, der selbst die größte Angriffsfläche ist: unauthentifizierter Download, unsigniertes Image, beschreibbarer Update-Server.
- Der **Fernzugriff des Lieferanten** auf eine Maschine, mit geteilten Zugangsdaten, die den Servicevertrag überdauern.

Die Angriffsfläche zu reduzieren ist die günstigste Sicherheitsmaßnahme, die es gibt: abschalten, was nicht gebraucht wird, authentifizieren, was gebraucht wird, den Rest segmentieren. Jede Schnittstelle, die vor dem Release geschlossen wird, ist eine Klasse künftiger Schwachstellen, die nie gefunden, gepatcht oder gemeldet werden muss. Die CRA-Anforderung ist intern ein gutes Argument: Dokumentiere jede in der Standardkonfiguration exponierte Schnittstelle mit dem Grund, warum sie exponiert sein muss. Schnittstellen ohne Grund werden geschlossen.

## Häufige Missverständnisse

Eine Angriffsfläche ist keine Schwachstellenzahl, und eine kleine ist nicht automatisch sicher: Ein unauthentifizierter Dienst reicht. "Nur intern erreichbar" ist keine Angriffsfläche von null, sondern eine, die nach der ersten Kompromittierung erreichbar wird. Und die Angriffsfläche ist nicht statisch. Jedes Firmware-Release, jede neue Cloud-Funktion und jede neue Lieferantenanbindung verändert sie. Deshalb muss die Karte gepflegt werden, nicht einmal gezeichnet.

## FAQ

**Was ist der Unterschied zwischen Angriffsfläche und Schwachstelle?**

Die Angriffsfläche ist, wo ein Angreifer das System berühren kann; eine Schwachstelle ist ein Fehler an einem dieser Punkte, der sich ausnutzen lässt. Eine große Angriffsfläche ist für sich keine Schwachstelle, aber jeder Punkt darauf ist ein Ort, an dem eine existieren kann und der getestet werden muss. Die Fläche zu verkleinern entfernt ganze Klassen künftiger Schwachstellen, ohne sie erst finden zu müssen.

**Verlangt der Cyber Resilience Act eine Reduktion der Angriffsfläche?**

Ja. Anhang I Teil I Nummer 2 Buchstabe h verlangt, dass Produkte mit digitalen Elementen so konzipiert, entwickelt und hergestellt werden, dass Angriffsflächen einschließlich externer Schnittstellen begrenzt werden. Praktisch heißt das: Jede in der Standardkonfiguration exponierte Schnittstelle braucht einen Grund, und Debug- und Testschnittstellen werden vor der Auslieferung geschlossen oder geschützt.

**Wie ermittelt ihr die Angriffsfläche im Penetrationstest?**

Schnittstelle für Schnittstelle: Netzwerkscans und Dienstenumeration, Funkaufnahmen für BLE, WLAN und proprietäre Verbindungen, Inspektion der Platine auf Debug-Ports und Speicher, Enumeration der Diagnosedienste auf Fahrzeugbussen, Review von Mobile App und Cloud-API und ein Blick auf den Update-Mechanismus. Das Ergebnis ist eine Liste, auf die sich Scoping, Test und Bericht beziehen.

## Sources

- [NIST CSRC Glossary: attack surface (NIST SP 800-53 Rev. 5)](https://csrc.nist.gov/glossary/term/attack_surface)
- [OWASP Cheat Sheet: Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)
- [Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil I Nummer 2 Buchstabe h](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)

## Related

- [Threat Modeling](https://zyberum.com/de/glossar/threat-modeling)
- [TARA (Threat Analysis and Risk Assessment)](https://zyberum.com/de/glossar/tara)
- [Debug-Schnittstellen (JTAG, SWD, UART)](https://zyberum.com/de/glossar/debug-schnittstellen-jtag-uart)
- [Cyber Resilience Act (CRA)](https://zyberum.com/de/glossar/cyber-resilience-act)
- [Pentest-Scoping-Checkliste: Was du vor dem Test klären musst](https://zyberum.com/de/insights/pentest-scoping-checkliste)
- [Wir brechen ein. Du bekommst den Beweis und den Fix.](https://zyberum.com/de/penetrationstest)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/glossar/angriffsflaeche