Mehr als oberflächlich : Vorgehensweisen zu Attack-Surface-Analysis und -Management (ASA/ASM)

Die Angriffsoberfläche ist in der Informations- und IT-Sicherheit ein häufig wiederkehrender Begriff und beschreibt die angreifbaren Teile der eigenen IT-Prozesse und -Infrastruktur – Vulnerabilität bezeichnet in diesem Kontext die Schwäche und mögliche Ausnutzbarkeit durch potenzielle Angreifer. Durch die verstärkte Nutzung von Cloud-Diensten, die Verwendung von Mikro-Services und der damit einhergehenden Aufweichung des Perimeterprinzips wird eine Bestimmung dieser Angriffsoberfläche immer wichtiger.

Ein weiterer Beweggrund der stärkeren Aufmerksamkeit für Analysen von Angriffsoberflächen ist in steigenden gesetzlichen Anforderungen zu verorten. Beispielsweise sind mit Inkrafttreten der NIS2-Richtlinie deutlich strengere Auflagen zur Erstellung von Risikoanalysen und Sicherheitskonzepten sowie der Meldung von Cyber-Security-Vorfällen einzuhalten. Die Bestimmung der Angriffsoberfläche leistet hierbei einen wesentlichen Beitrag zur zielgerichteten Verbesserung der eigenen Resilienz. Das betrifft alle drei Bereiche: Governance, Entwicklung und Betrieb – dementsprechend weitreichend können Auswirkungen notwendiger Änderungen durch die Durchführung einer Attack-Surface-Analysis (ASA) sein.

Der vorliegende Artikel legt in praktischer Weise dar, wie man eine solche Analyse initiieren kann und beschreibt exemplarisch ein mögliches Vorgehen für die ASA. Ziel ist es, mithilfe der Ergebnisse moderne Architekturen im Enterprise-Umfeld abzusichern. Zentrale Prämisse ist dabei einmal mehr die Angreiferperspektive.

Vorgehensweise:

Aus Projektsicht reicht die Fokussierung auf die Implementierung und das Abprüfen von IT-Sicherheitsregelungen im Rahmen des Informationssicherheits-Managements oft nicht aus. Beispielsweise können Schatten-IT und dezentral gemanagte Cloud-Dienste die Sicherheit der gesamten betrachteten Organisation unterminieren. Die Analyse der Angriffsoberfläche leistet einen wichtigen Beitrag zum Auffangen der zusätzlichen In Zeiten stark verflochtener Dienste und agiler Bereitstellung neuer Systeme und Services sollte eine intensive und regelmäßige Erhebung der eigenen Angriffsoberfläche im Rahmen von Attack-Surface-Analysis und -Management (ASA/ASM) ein wesentliches Element jeder Sicherheits-Strategie sein, empfiehlt unser Autor. Wie das aussehen kann, beschreibt er im vorliegenden Beitrag. Management und Wissen Angriffsoberfläche Risiken heutiger IT-Infrastruktur und verbindet ganz praktisch aktuelle Anforderungen mit dem bestehenden Informationssicherheits-Managementsystem (ISMS). Es berücksichtigt gleichzeitig zeitliche Faktoren, Nutzerverhalten und moderne Architekturen. Für die Durchführung der Analyse sollten die folgenden fünf Schritte durchlaufen werden:

• Zielsetzung / Umfangsbestimmung für das Attack-Surface-Management (ASM): Am Anfang stehen Festlegungen zur Angriffsoberfläche – sie liefern zudem eine Handhabe, welche Arten von Assets im Rahmen der Analyse mit einfließen sollen. Die Definition möglicher Bedrohungsszenarien auf die zu betrachtenden Assets hilft, den Umfang passgenau an den eigenen Bedürfnissen zu orientieren.
• Bestimmung der Exposition von Assets: Für die Bestandsaufnahme der infrage kommenden Assets wird ermittelt, welche davon beispielsweise via Internet öffentlich zugänglich exponiert sind. Die Klärung der Sichtbarkeit nach „außen“ bestimmt bereits die Angriffsoberfläche. Eine besondere Bedeutung hat dabei die Bestimmung von Schnittstellen und Datenübergängen.
• Abprüfen identifizierter Angriffspunkte durch praktische Tests: Für die zu bestimmenden Schutzmaßnahmen gibt es eine Vielzahl möglicher Tests, die sich am gewünschten Umfang der ASA orientieren und ihr Ziel beeinflussen.
• Überprüfung der Schnittpunkte zum ISMS: Mit den Ergebnissen der praktischen Tests lässt sich beim Vorhandensein eines etablierten ISMS ein Abgleich durchführen, ob gefundene Angriffsvektoren in den Guidelines und Policies des ISMS und durch entsprechende Maßnahmen bereits berücksichtigt sind.
• Ableitung beziehungsweise Ergänzung der Regelungen und Integration in das bestehende ISMS: Abschließend werden Sicherungsmaßnahmen umgesetzt und Regelungen hierfür in das ISMS aufgenommen.

Jedwede Applikation und jedweder Prozess haben das Potenzial, die mögliche Angriffsoberfläche zu vergrößern. In der nachfolgenden Vertiefung sollen besonders Beispiele moderner Architekturen zur Illustration des vorgeschlagenen Vorgehens dienen.

Umfangsbestimmung

Angriffsoberfläche bezeichnet die gemeinsame gedankliche Oberfläche von eigener IT-Infrastruktur, Prozessen, Services und Mitarbeitern (nachfolgend Assets genannt), die sich durch Schwachstellen kompromittieren lassen. Bei der Definition der auf ein Asset bezogenen Angriffsoberfläche ist im ersten Schritt die gewünschte Dimension bzw. Granularität der zu betrachtenden Oberflächen zu klären. Will man beispielsweise einzelne Mitarbeiter und Prozesse oder aber die gesamte genutzte Infrastruktur für Services analysieren?

Unabhängig davon, ob ein neues Produkt, ein einzelner Dienst oder gar eine gesamte Infrastruktur (inklusive der darauf laufenden Prozesse) analysiert werden sollen, ist die Angriffsoberfläche immer größer als die „gesicherte Nutzungsoberfläche“, die aus der sicheren Nutzung der einzelnen Assets resultiert. Das Ziel einer ASA muss immer die Verringerung des Verhältnisses zwischen Angriffsoberfläche und Nutzungsoberfläche sein. Hierzu dekonstruiert man die Assets in ihre einzelnen Komponenten/Bestandteile und ordnet ihnen Verantwortlichkeiten zu – man identifiziert die jeweiligen Services, die miteinander kommunizieren, und zeichnet die Kommunikation der Assets untereinander nach.

Im Fokus steht dabei die Sichtbarkeit der betrachteten Dienste – dementsprechend sind sowohl Aspekte des Asset- und Supply-Chain-Managements als auch von Bedrohungs- und Schwachstellenmanagement, Release- und Patchmanagement sowie des Security-Incident-Managements zu berücksichtigen. Die für all diese Prozesse notwendige Dokumentation ist ein wesentlicher Grundpfeiler, um im ersten Schritt den Umfang der ASA bestimmen zu können. Je mehr Dokumentation es schon gibt, desto geringer ist der zusätzliche Aufwand. Aufbau und Komponenten der Assets lassen sich zum Beispiel aus Configuration-Management-Databases (CMDBs) und/oder Verfahrensverzeichnissen entnehmen – idealerweise sind hierbei bereits Informationen über Verantwortliche und Beziehungen zu anderen Assets enthalten.

Ein weiterer essenzieller Aspekt ergibt sich aus der Kritikalität und den Auswirkungen beim Ausfall eines Services oder einer Komponente. Dementsprechend genau sollte man die jeweiligen Assets „unter die Lupe“ nehmen und priorisieren.

Zu den wichtigen Assets zählen heute längst nicht mehr nur On-Premises-Dienste, Infrastruktur und Prozesse, sondern auch Cloud-Assets (z. B. eine Virtual Private Cloud, VPC, oder der Account der AWS-Managementkonsole).

Besonderes Interesse bei der Analyse der Angriffsoberfläche sollte darüber hinaus automatisierten Prozessen und Abläufen gelten. Beispielsweise lassen sich dort Token für die Authentifizierung/Autorisierung auch für Angriffe missbrauchen. Das feste Einbinden von Credentials in Programm-Code kann es Angreifern ebenfalls ermöglichen, die Autorisierung auszuhebeln. Das Wissen um verwendete Maschinenaccounts und/oder Token sowie verwendete Technologie und Protokolle erleichtert die Analyse ungemein und zeigt klare Ansatzpunkte für das weitere Vorgehen auf. Eine wesentliche Rolle spielt in diesem Kontext auch das Supply-Chain-Management.

Die Erfassung von Informationen zur verwendeten Infrastruktur bei Fremdprodukten, z. B. durch sogenannte „Software Bills of Materials“, also die Auflistung der genutzten Software und ihrer einzelnen Komponenten, liefert ebenfalls Indikatoren zur Verwundbarkeit. Hierzu ist ein Abgleich mit Informationen aus Schwachstellenreports durchzuführen – dabei werden Informationen wie Versionen der eingesetzten Bibliotheken, Protokolle und deren Abhängigkeiten abgefragt und ausgewertet. Eine automatisierte Erfassung (z. B. über Standards wie Cyclone DX) hilft dabei, die notwendigen Informationen in maschinenlesbarer Form verwertbar zu machen.

Etablierte Prozesse zum Sammeln aktueller Bedrohungsinformationen (Threat-Intelligence, TI) liefern einen wertvollen Beitrag zur Abschätzung möglicher Risiken und deren Auswirkungen. Einschätzungen, wie relevante Angreifer vorgehen, lassen sich dabei branchenspezifisch ermitteln und beschränken so die Plausibilität bestimmter Szenarien. Die Priorisierung anhand der Sparte sowie das Wissen um Angreifertaktiken, -techniken und -prozeduren (Tactics, Techniques and Procedures – TTPs) helfen, die Bedrohungslage für das eigene Unternehmen besser abzuschätzen.

Die Bedrohungslage fungiert dann quasi als Filter zur spezifischen Einschränkung und Konzentration sowie Identifizierung möglicher Angriffspunkte/-vektoren und Angreifer (vgl. Abb. 2). Daran sollte sich auch die Vorfallbehandlung im Kontext des Security-Incident-Managements orientieren.

Vorhandene Informationen in Listen eingesetzter Software aus Configuration-Management-Databases (CMDBs), Use-Case-Betrachtungen für das zentrale Risiko- und Business-Continuity-Management helfen ebenfalls, den Aufwand der Umfangsbestimmung im Rahmen zu halten. Architekturübersichten und Netzpläne runden das Gesamtbild ab. Flankierend dazu erzeugen oder verbessern Erkenntnisse aus Interviews mit Anwendern, Entwicklern und Architekten die notwendige Sichtbarkeit.

Für eine praktikable Anwendung sollte man im ersten Schritt das Bedrohungsmodell noch auf einer recht abstrakten Ebene belassen. Diese lässt sich dann durch die Auswahl relevanter Angriffe anhand von Threat-Intelligence, -Personas sowie Erkenntnissen des Threat-Hunting weiter verfeinern. So können sowohl aktuelle Angriffsarten als auch mögliche Angreifertypen in die Analyse einfließen. Als gängige Ansätze für das Threat-Modeling kommen ATT&CK (https://attack.mitre.org, vgl. [4]), STRIDE (Spoofing – Tampering – Repudiation – Information disclosure – Denial of Service – Elevation of privilege) oder der „Process for Attack-Simulation and Threat-Analysis“ (PASTA) infrage.

Ziele der Analyse

Abschließend ist die Zielsetzung zu erörtern: Die zusammengetragenen Informationen können etwa Security-Testern und/oder -Beratern zur Verfügung gestellt und ein entsprechendes Testkonzept entwickelt werden. Gemeinsame Workshops mit Key-Stakeholdern, wie dem Management, sollten das erzeugte Gesamtbild der Assets und den Zielrahmen der Analyse validieren.

Besonders wichtig ist, wie mit den Ergebnissen umgegangen werden soll, da dies eine direkte Auswirkung auf die Art und Weise der Attack-Surface-Analysis (ASA) besitzt. Nachvollziehbar wird das zum Beispiel durch die mögliche Feststellung, dass bestehende, im ISMS definierte Sicherheitsmaßnahmen für zentrale Accounts nicht ausreichend den Nutzerlebenszyklus abdecken. Hierfür wäre eine eher prozessuale Ausrichtung der Tests zielführend. Demgegenüber stünde beispielsweise das Ziel, passende Testzyklen und -umfänge für Pen-Tester zu generieren: Hierzu würde man eher technische Systeme der Analyse unterziehen.

Bestimmung der Exposition

Zentraler Punkt bei einer Attack-Surface-Analysis ist die ganzheitliche Betrachtungsweise im Sinne der Informationssicherheit: Eine Einschränkung auf die rein technische oder prozessuale Angriffsoberfläche verzerrt die Ergebnisse der Analyse und erhöht die Gefahr „weißer Flecken“ auf der Landkarte der zu schützenden Assets.

Für das Bestimmen des Grades der Exponiertheit verwendet man zum einen die gewonnenen Erkenntnisse aus den Workshops für das Umfang-Management und kombiniert diese mit der entsprechenden Exposition – also die Verfügbarkeit und/oder Zugänglichkeit für Angreifer. Die zentrale Frage bei diesem Schritt lautet, welcher digitale Fußabdruck beim betrachteten Umfang sichtbar wird (vgl. Abb. 3).

Alle möglichen Services, die durch Nutzer (seien es Maschinen, Prozesse oder selbst wieder Services) direkt verwendet werden können, sind naturgemäß potenzielle Angriffspunkte. Gerade durch die Modularisierung, „Cloudifizierung“ und Containerisierung vergrößert sich die Angriffsoberfläche: Applikationen werden komplexer und damit erhöhen sich oft auch die Zahl der Endpoints und so die Möglichkeiten für einen erfolgreichen Angriff.

Beispielsweise befeuert die Nutzung von Microservices diese Entwicklung, denn diese bringen schon durch ihr inhärentes Design, lose gekoppelte Services über definierte Schnittstellen kommunizieren zu lassen, eine erhöhte Visibilität nach außen und somit neue Angriffsvektoren mit sich.

Die Sichtbarkeit nach außen wird aber nicht nur bewusst erzeugt (z. B. über das Bereitstellen von API-Endpunkten oder alternative Zugangspunkte/Wartungszugänge). Angriffsvektoren können auch durch Fehler in der Konfiguration, Programmier- und Prozessfehler entstehen.

Zur Bestimmung der Exposition werden mögliche Angriffspunkte beziehungsweise die betrachtete Infrastruktur mit Scans und Schwachstellentests geprüft (zu Tools siehe Tab. 1). Diese Tests erfolgen nacheinander für die einzelnen Komponenten – die Auswahl der Systemkomponenten, Prozesse und Nutzer orientiert sich dabei an den im ersten Schritt identifizierten Bedrohungsmodell. Dabei sollte man besonders viel Wert auf die Bestimmung der Schnittstellen und Datenübergänge legen.

Zum Einsatz können dabei die gleichen Werkzeuge kommen, die auch Angreifer einsetzen. In diesem Kontext könnte man von „Reconnaissance“ im klassischen Sinne sprechen: Sowohl passive als auch aktive Techniken und Tools zeichnen letzten Endes das große Bild und damit die Landkarte, die eine Organisation für den Schutz ihrer betrachteten Infrastruktur benötigt.

Viele Systeme bieten Möglichkeiten, ihre Funktionen über Plug-ins deutlich zu erweitern. Gute Beispiele hierfür sind die „Burp Suite“ (https://portswigger.net/burp) oder auch das OWAPS „Zed Attack Proxy“ (ZAP, www.zaproxy.org). In Kombination mit dem „Attack Surface Detector“ lassen sich Änderungen der Angriffsoberfläche betrachteter Applikationen über die Zeit hinweg überwachen, wobei systemseitig Funktionen und neue Endpunkte im Fokus liegen (https://owasp.org/www-project-attack-surface-detector/).

Prüfen identifizierter Angriffspunkte durch praktische Tests Mithilfe der ausgewählten Werkzeuge gilt es, die einzelnen identifizierten Komponenten und Dienste durchzugehen. Einer initialen Erhebung der Angriffsoberfläche sollten regelmäßige Tests folgen, die im Idealfall durch flankierende automatisierte Tests begleitet werden. Für Microservices bietet sich hier eine Integration von Scannern in die Continuous-Integration/Delivery-(CI/ CD)-Pipelines an (z. B. in Form von Dynamic oder Static Application-Security-Testing, DAST/SAST). Die initial gesammelten Analysedaten und Schwachstelleninformationen dienen dann als Grundlage/Baseline für spätere Vergleiche.

Neben dem automatisierten Ermitteln der Angriffsoberfläche ist die Analyse von Prozessen mit Auswirkungen auf den Entwicklungsprozess ebenso wichtig. Für die Identifikation von Angriffspunkten können dabei beispielsweise Code-Reviews einen wertvollen Beitrag leisten. Ein generelles Vier-Augen-Prinzip, die Umfangs-Definition der Code-Reviews und die Dokumentation vorgeschlagener Änderungen tragen dann ganz nebenbei zur Steigerung der Codequalität und zur Minimierung von Sicherheitsrisiken bei. Ansätze für die Umsätze für Code-Reviews liefern beispielsweise „Google’s Code Review Guidelines“ (https://google.github.io/eng-practices/).

Weitere Ergebnisse lassen sich durch Tabletop-Exercises generieren – besonderes Augenmerk verdient dabei die Identifizierung möglicher Angriffspunkte als ein Teilziel durch die Suche nach möglichen Schwachpunkten im Betrieb der betrachteten Services.

Neben dem reinen Scannen nach Schwachstellen kann Pen(etration)-Testing darüber hinaus einen wertvollen Beitrag leisten, um völlig neue Angriffspunkte zu identifizieren, wenn etwa auch physische Zugriffe und/oder Social Engineering-Methoden eingebunden werden.

Mit Red- und Blue-Team-Übungen, also dem Durchspielen ganzer Angriffsszenarios (z. B. durch den Einsatz der Toolsets bekannter Angreifergruppen – vgl. ATT&CK) lassen sich auch großflächigere Analysen durchführen. Der Vorteil hierbei ist das gleichzeitige Prüfen von Security-Incident-Response-Fähigkeiten auf technischer Ebene: Hierbei kommen bereits erstellte Incident-Response-Playbooks zum Einsatz – quasi Drehbücher, die beschreiben, wie eine Reaktion auf mögliche Angriffe auszusehen hat.

Sollte ein solches Drehbuch noch nicht vorhanden sein, bieten eine ganze Reihe von Organisationen und Firmen praktische Hilfen und Materialien für das Erstellen (siehe etwa www.incidentresponse.org/playbooks/).

Aus Sicht des Autors ist eine initiale Erstellung und Betrachtung von Playbooks in einem separaten Projekt unerlässlich, da ein solches Dokument zentral beschreibt, welche Rollen und Aufgaben die mit der Vorfallsbehandlung beauftragten Personen, Teams und Abteilungen über die unterschiedlichen Phasen eines solchen Incidents hinweg einnehmen sollen – und wie die Kommunikation über und zum Angriff nach innen und außen effektiv gesteuert werden soll. Zusätzlich werden auch alle weiteren Aspekte von der Vorbereitung bis zum Punkt der „Lessons learned“ spezifisch auf die betrachtete Organisation behandelt. Und nicht zuletzt ebnet ein solches Dokument den Weg für schnelle und zielgerichtete Entscheidungen, da deren Grundlage bereits vordefiniert ist und im Notfall nicht erst mühsam erarbeitet werden muss.

Überprüfung der Schnittpunkte zum ISMS und Ableitung neuer Regelungen

Mithilfe der ASA-Ergebnisse lassen sich schnell mögliche Handlungsfelder identifizieren. Im Regelfall handelt es sich um ein buntes Potpourri an Schwachstellen, problematischen Handlungsweisen und Berichten – beispielsweise:

• Anzeige von Standardfehlermeldungen bei API-Aufrufen (Error-Pages)
• veraltete API-Versionen, die noch von außen erreichbar sind
• Zugriffsmöglichkeit auf veraltete API-Dokumentation
• global zugängliche API-Parameter, obwohl diese nur lokal für einzelne Objekttypen verwendet werden sollten
• Durchlaufen von Verzeichnissen (Directory-Traversal) ist möglich, sodass sich beispielsweise Konfigurationsdateien remote auffinden, auslesen und im schlimmsten Fall sogar ändern lassen
• fehlende Begrenzung von Anfragen – das heißt: konsumierte Services können immer und immer wieder aufgerufen werden und so die Kapazitätsgrenze möglicher Anfragen überschreiten
• Standard-Accounts und Default-Passwörter sind aktiv
• Wartungszugänge der Hersteller sind erreichbar und nur durch bekannte Default-Passwörter „geschützt“
• Möglichkeit von Injection-Attacks (z. B. SQL-Injection) durch fehlende Validierung von Eingabewerten
• Möglichkeit für Nutzer, „ungemanaged“ Software zu installieren und/oder Software durch Plug-ins zu erweitern

Die gefundenen Ergebnisse sollte man priorisiert nach Auswirkung und Tragweite der Schwachstellen mit den Regelungen des ISMS abgleichen. Der Abgleich bezüglich der ermittelten Kritikalität bestimmt anschließend die Reihenfolge der Bearbeitung. Als erste Einschätzung kann das „Common Vulnerability Scoring System“ (CVSS) mögliche probate Maßzahlen liefern. Wichtig ist allerdings auch, die Umgebungsfaktoren (Environmental-Score) mit in die Einschätzung aufzunehmen (Berechnung etwa mit www.first.org/cvss/calculator/3.1).

In den vorliegenden Beispielen wären hier etwa Guidelines für Web-Applikationen und -Entwicklung sowie Hardening zu prüfen. Als Prüffrage kann dabei die Realisierbarkeit der identifizierten Schwachstellen unter dem Regime des implementierten ISMS dienen: Verhindern Regelungen und Policies des ISMS die Ausnutzung der gefundenen Schwachstelle? Bei negativer Beantwortung dieser Fragestellung ist eine Anpassung notwendig.

Ableitung/Ergänzung der Regelungen und Integration in ein bestehendes ISMS

Im letzten Schritt werden dann die Richtlinien und Policies dahingehend erweitert, dass die Ausnutzung der gefundenen Schwachstellen nur noch durch eine direkte Verletzung derselben möglich ist. Gleichzeitig stellen die neuen Gegenmaßnahmen quasi eine Art Lackmustest für die neuen Regelungen dar.

So könnte man etwa (um erneut ein paar Beispiele aus der obigen Aufzählung aufzugreifen) Anforderungen bezüglich des Entwicklungsprozesses dahingehend erweitern, dass neue Versionen von Applikationen auch die Überprüfung der Verfügbarkeit und Aktualisierung der bestehenden Dokumentation erfordern sowie die Einschränkung von API-Versionen auf die jeweils gültige verbindlich macht – alte Versionen wären damit also „abzuschalten“.

Natürlich sollten immer nur notwendige Web-Services über das Internet zugänglich sein – das Release- und Deployment-Management von Diensten sollte daher die Aktualisierung der Dokumentation und Deaktivierung nicht genutzter Endpunkte mit einschließen und zum Beispiel auch eine Inventarisierung für Endpunkte zur Pflicht erheben.

Fazit

Die Angriffsoberfläche ist ein Ausdruck der Komplexität und Sichtbarkeit von Schwachstellen nach außen. Nur durch ein konstantes Monitoring und durch geeignete Maßnahmen, wie Awareness-Kampagnen auf unterschiedlichen Ebenen, Weiterbildung und Schulungen für Secure-Coding-Principles sowie Threat-Modeling, kann man versuchen, die Angriffsoberfläche nicht noch weiter zu vergrößern, sondern sogar zu minimieren.

Die Analyse der Angriffsoberfläche ist im Rahmen der Inbetriebnahme und Sichtbarmachung neuer Services von besonderer Wichtigkeit und sollte mit jedem neuen Release aktualisiert werden. Dieser zeitliche Aspekt hilft, die Angriffsoberfläche dauerhaft möglichst klein zu halten.

Marko Klaus ist Projektleiter und Principal Consultant Informationssicherheit bei T-Systems MMS.

Literatur

[1] Marko Klaus, Kettenreaktionen, Supply-Chain-Attacken – Bedrohung und Abwehr, <kes> 2021#5, S. 56
[2] Marko Klaus, Andreas Lang, Enrico Weide, Dominik Weißhaar, AMD&IS, Angreifermodell für den Datenschutz und die IT-Sicherheit, <kes> 2021#2, S. 16
[3] Marko Klaus, Mechthild Stöwer, Metriken aus Angreifer-Sicht, <kes> 2020#1, S. 43
[4] Felix Blank, Perspektivwechsel mit System, Wie das Mitre ATT&CK Framework bei der Vorsorge und Abwehr von Angriffen helfen kann, <kes> 2020#5, S. 15