Sicherheitsscans: Geltungsbereich und Erlaubnis prüfen

Der Geltungsbereich eines Sicherheitsscans legt fest, welche Systeme, Dienste und Verfahren eine Prüfung unter welchen Bedingungen umfassen darf. Ein entdeckter Hostname oder eine aufgelöste IP-Adresse belegt zunächst einen technischen Zusammenhang. Klären Sie vor den ersten Testanfragen, wer diese konkrete Prüfung erlauben kann, welche Ausschlüsse gelten und wer sie unterbrechen kann, wenn sich das Ziel oder die Erlaubnis ändert.

Diese Unterscheidung wird besonders relevant, wenn Ihr Firmenname in Anfragen auftaucht, die auf einem fremden Server eingehen. Ein Werkzeug kann einen tatsächlichen Zusammenhang erkennen und trotzdem die Grenzen Ihrer beauftragten Prüfung falsch ziehen.

Am 13. September berichtete der ehrenamtliche Betreiber eines Zeitservers von unerwarteten Anfragen aus Sicherheitstests. Sie enthielten einen Tesla-Hostnamen und Kennungen mit Bezug zu Assetnote. Der Betreiber vermutete, ein DNS-Alias zu einem gemeinsam genutzten Zeitserver-Pool könnte die Auswahl des Ziels erklären. Er bezeichnete diese Erklärung ausdrücklich als Spekulation. Inzwischen steht auf der Seite, dass Assetnote ihn kontaktiert hat und die Angelegenheit geklärt wurde. Die Darstellung belegt weder eine vom Anbieter bestätigte Ursache noch eine erfolgreiche Kompromittierung.

Für Ihr Team stellt sich eine Frage, die über diesen Bericht hinausgeht: Welche Nachweise machen aus einem entdeckten System ein zulässiges Scan-Ziel? Das folgende Vorgehen ist unsere praktische Empfehlung, erläutert an fiktiven Systemen. Es hilft Ihnen, den eigenen Prozess zu prüfen. Es ist keine Aussage über die internen Kontrollen der beiden Unternehmen.

Was umfasst der Geltungsbereich eines Sicherheitsscans?

Eine Prüfung braucht klare Grenzen für den untersuchten Dienst und die dort erlaubten Handlungen. Eine bloße Liste von Systemen lässt zu viele Fragen offen.

Nehmen wir das fiktive Unternehmen Example Works mit einer Anwendung unter app.example.com. Ihr Anwendungsteam verwaltet möglicherweise den Code und die Kundenkonfiguration, während ein Anbieter die darunterliegende Netzwerkinfrastruktur betreibt. Die Erlaubnis, die Anwendung zu testen, klärt noch nicht, ob Sie andere Dienste unter derselben Adresse untersuchen, den Mandanten eines anderen Kunden testen oder Verfahren einsetzen dürfen, die den Betrieb beeinträchtigen.

Beschreiben Sie den Geltungsbereich so, dass Prüfer drei Fragen ohne Mutmaßungen beantworten können: Was darf Anfragen erhalten, welche Handlungen sind erlaubt und welches Ereignis erfordert eine Unterbrechung? Halten Sie auch die jeweilige Umgebung und Kontozuordnung fest. Eine Produktionsanwendung und ihre Staging-Kopie können unterschiedliche Zuständigkeiten, Datenbestände und Betriebsbedingungen haben, auch wenn die Namen ähnlich aussehen.

NIST SP 800-115, Abschnitt 6.5, beschreibt die Planung von Prüfungen mit zugelassenen und ausgeschlossenen Systemen, Testaktivitäten, organisatorischen Abläufen, dem Umgang mit Daten und Verfahren bei Vorfällen. Auch die Zustimmung Dritter und die Befugnis zur Wiederaufnahme unterbrochener Tests werden behandelt. Die Leitlinie wurde 2008 veröffentlicht; sie ist keine neue Anforderung für 2026.

Wählen Sie den Detailgrad passend zum Auftrag. Für eine eng begrenzte Anwendungsprüfung kann eine kurze Beschreibung reichen. Wiederkehrende Prüfungen in wechselnder Infrastruktur brauchen gepflegte Unterlagen und einen Weg, Änderungen vor der Ausführung zu prüfen. In beiden Fällen sollte jemand erklären können, warum die nächste Anfrage innerhalb des erlaubten Geltungsbereichs liegt.

Wohin kann ein entdeckter Hostname führen?

Ein Hostname kann einen von Ihnen genutzten Dienst bezeichnen, ohne dass Sie alles dahinter kontrollieren. Bewahren Sie den Fundnachweis auf, klären Sie aber die Beziehung zum Dienst, bevor Sie aktive Tests zulassen.

Die folgenden Beispiele sind fiktiv. Sie zeigen offene Fragen, keine Regeln, die ein Ziel automatisch freigeben oder ausschließen.

Gemeinsam genutzte Infrastruktur ist nicht automatisch von Tests ausgeschlossen. Sie können durchaus berechtigt sein, Ihre Anwendung über die vorgeschaltete Infrastruktur eines Anbieters zu prüfen. Die Abgrenzung versagt, wenn sich diese Erlaubnis stillschweigend auf andere Mandanten, Ports oder Dienste ausdehnt, nur weil sie dieselbe Adresse nutzen.

Die Hinweise des NTP Pool für Anbieter beschreiben Regelungen für Produkte, die den Pool als voreingestellten Zeitdienst nutzen, einschließlich eigener Anbieter-Hostnamen. Diese Regelungen betreffen die Nutzung eines Zeitdienstes. Für sich genommen begründen sie keine Erlaubnis, die von Freiwilligen betriebenen Server Sicherheitstests zu unterziehen.

Behalten Sie ausgeschlossene Abhängigkeiten im Inventar. Ihr Sicherheitsteam muss möglicherweise weiterhin deren Konfiguration prüfen, Sicherheitsnachweise mit dem Anbieter besprechen oder einen Ersatz planen. Wenn ein Dienst aus aktiven Tests herausgenommen wird, darf seine Bedeutung für Ihr Unternehmen nicht aus dem Blick geraten.

Was sollten Sie vor aktiven Tests dokumentieren?

Führen Sie neben dem Systeminventar einen knappen Nachweis zur Testerlaubnis. Er sollte das System mit den Belegen, Einschränkungen und der für diese Prüfung verantwortlichen Person verbinden.

Wir schlagen die folgenden Felder vor. Passen Sie sie an den Auftrag an, statt sie als starres Compliance-Formular zu behandeln:

• Dienstidentität: Hostname, Umgebung sowie die relevante Mandanten-, Konto- oder Ressourcenkennung.
• Verantwortliche Personen: fachlich verantwortliche Person, tatsächlicher Betreiber und Prüfungsverantwortlicher.
• Fundnachweis: wie Sie das System entdeckt haben und welchen Zusammenhang dieser Nachweis belegt.
• Erlaubnisnachweis: freigegebener Prüfauftrag, einschlägige Anbieterrichtlinie oder konkrete Vereinbarung samt Einschränkungen.
• Zulässige Arbeiten: Verfahrensarten, Ausschlüsse, erlaubte Konten und Vorgaben zum Umgang mit Daten.
• Gültigkeitsbedingungen: abgedeckter Zeitraum oder abgedeckte Umstände sowie Änderungen, die eine erneute Prüfung erfordern.
• Ausführungsbezug: Scan-Konfiguration oder Prüfauftrag, der die genehmigten Grenzen umsetzt.
• Kontakt für Unterbrechungen: wer die Arbeiten unterbrechen und wer ihre Wiederaufnahme erlauben kann.

Verlangen Sie nicht für jeden Eintrag eine neue Zustimmung per E-Mail. Eine veröffentlichte Anbieterrichtlinie kann bestimmte Tests unter den genannten Bedingungen bereits erlauben. So unterscheidet die Richtlinie von AWS für Penetrationstests zwischen erlaubten Prüfungen der kundeneigenen Infrastruktur und Tests der Infrastruktur oder Dienste von AWS selbst. Entscheidend sind der konkrete Dienst und seine Bedingungen. Ein allgemeiner Verweis auf einen Cloud-Anbieter reicht nicht.

Verwenden Sie eindeutige Statusangaben, damit aus einer Entdeckung nicht unbemerkt eine Ausführung wird. Unser Vorschlag: entdeckt, Verifizierung ausstehend; verifiziert, für diese Prüfung nicht freigegeben; mit Einschränkungen freigegeben; und bis zur Klärung pausiert. Das sind vorgeschlagene Prozesszustände, keine in Kit eingebauten Systemstatus.

Der fiktive Support-Mandant von Example Works könnte verifiziert, aber nicht freigegeben bleiben, während die verantwortliche Person die Anbieterrichtlinie prüft. Der Zusammenhang besteht, und das Inventar bleibt nützlich. Für die Aufnahme in die aktive Prüfung fehlt noch die Grundlage. Das ist ein reguläres Ergebnis, kein offener Verwaltungspunkt, den jemand mit einem Klick auf „Freigeben“ erledigen sollte.

Wie bleibt ein laufender Scan innerhalb der erlaubten Grenzen?

Die laufende Prüfung muss die freigegebenen Dienstgrenzen einhalten. Prüfen Sie, wie Ihre Werkzeuge aus Hostnamen, Weiterleitungen und neuen Funden ausführbare Aufträge machen.

Beginnen Sie bei der Übergabe vom Inventar an den Scanner. Wenn Sie einen Anwendungs-Hostnamen freigeben, sehen Sie nach, ob der nächste Schritt diese Anwendung testet oder den Auftrag auf die aufgelösten Adressen ausweitet. Für eine Verbindung kann es nötig sein, einen Hostnamen in eine Adresse aufzulösen. Daraus eine Erlaubnis für jeden Dienst unter dieser Adresse abzuleiten, ist eine andere Entscheidung.

Stellen Sie dieselbe Frage bei Weiterleitungen und automatisierter Erkundung. Ein Link zur Anmeldeseite eines Anbieters kann eine nützliche Entdeckung sein, ohne die Prüfung auf diesen Anbieter auszudehnen. Legen Sie fest, ob das Werkzeug stoppt, das Ziel zur Prüfung vormerkt oder auf Grundlage einer bereits passenden Erlaubnis fortfährt. Wer den Durchlauf freigibt, muss dieses Verhalten nachvollziehen können.

Änderungen der Infrastruktur erfordern eine angemessene Prüfung. Eine Ersatzinstanz innerhalb desselben freigegebenen Kontos und derselben Dienstgrenzen kann bereits abgedeckt sein. Ein neues Ziel außerhalb dieser Grenzen erfordert eine Entscheidung. Erzwingen Sie nicht bei jeder routinemäßigen Adressänderung eine manuelle Freigabe. Definieren Sie, welche Bedingungen zur Identität und Zuordnung weiterhin erfüllt sein müssen.

Prüfen Sie auch bereits eingereihte Aufträge. Ein Ziel aus dem nächsten Inventarexport zu entfernen, sagt noch nichts darüber aus, was mit geplanten oder laufenden Aufträgen geschieht. Verifizieren Sie, wie Ihre Prüfwerkzeuge ausstehende Arbeiten abbrechen, Wiederholungsversuche behandeln und Ausschlüsse über alle Worker hinweg anwenden. Diese Fragen betreffen die Implementierung und Konfiguration Ihres Scanners. Ein Dokument zum Geltungsbereich kann das nicht garantieren.

Bewahren Sie für jeden Durchlauf die verwendete Fassung des Geltungsbereichs sowie ausreichend Ausführungsnachweise auf, um eine gemeldete Anfrage ihrer Prüfung zuordnen zu können. Beschränken Sie den Zugriff auf sensible Beispiele. Später müssen Sie eine konkrete Frage beantworten können: Welchen freigegebenen Dienst sollte dieser Auftrag auf welcher Erlaubnisgrundlage testen? Ein Screenshot der aktuellen Konfiguration erklärt keine Anfrage, die unter den gestrigen Einstellungen gesendet wurde.

Wie sollte eine Meldung über ein falsches Ziel zum Stopp führen?

Sorgen Sie dafür, dass Meldungen über unerwünschte Testanfragen direkt jemanden erreichen, der die Prüfung unterbrechen kann. Die meldende Person sollte keine prämienberechtigte Schwachstelle nachweisen müssen, bevor Ihr Team das Ziel überprüft.

Ein Kontakt für Schwachstellenmeldungen erleichtert es anderen, Sie zu erreichen. RFC 9116, Abschnitt 5.5, stellt klar, dass weder das Vorhandensein noch das Fehlen von security.txt eine Testerlaubnis impliziert. Behandeln Sie Kontaktweg und Testrichtlinie als getrennte Dinge und halten Sie beides verständlich.

Dem beauftragenden Team empfehlen wir folgenden Ablauf:

1. Unterbrechen Sie die betroffenen Arbeiten. Identifizieren Sie die Prüfung oder das Ziel genau genug, um die gemeldeten Anfragen während der Untersuchung zu stoppen.
2. Sichern Sie ein Minimum an Beispieldaten. Bitten Sie um Zeitstempel und relevante Anfragekennungen. Verbreiten Sie keine sensiblen Anfrageinhalte oder Zugangsdaten über Benachrichtigungen mit großem Empfängerkreis.
3. Ermitteln Sie den Prüfungsverantwortlichen. Ordnen Sie die Meldung der Person zu, die den Auftrag erteilt hat und seinen Geltungsbereich ändern kann.
4. Gleichen Sie das Ziel ab. Gleichen Sie Dienstidentität, tatsächlichen Betreiber und Erlaubnisnachweise mit dem ausgeführten Auftrag ab.
5. Korrigieren Sie die Ausführung ebenso wie die Unterlagen. Berichtigen Sie das Ziel oder den Ausschluss und berücksichtigen Sie eingereihte Anfragen, Wiederholungsversuche und wiederkehrende Zeitpläne.
6. Verifizieren Sie den Stopp. Bestätigen Sie anhand der Ausführungsnachweise, dass die betroffenen Anfragen aufgehört haben. Fragen Sie gegebenenfalls beim meldenden Betreiber nach, ob seine Beobachtungen damit übereinstimmen.
7. Geben Sie Rückmeldung. Erläutern Sie, was unterbrochen oder korrigiert wurde, und nehmen Sie nur Arbeiten wieder auf, deren Erlaubnis geklärt ist.

Nennen Sie keine Ursache als gesichert, bevor Sie die Fakten geprüft haben. Eine hilfreiche erste Antwort bestätigt den Eingang, nennt die für die Untersuchung verantwortliche Person und teilt mit, dass die betroffene Prüfung pausiert ist. Eine spätere Antwort kann bestätigte Erkenntnisse von verbleibenden Unklarheiten trennen.

Das hängt mit der koordinierten Offenlegung einer Schwachstelle über mehrere Anbieter hinweg zusammen, setzt aber früher an. Hier müssen Sie zunächst klären, wohin die von Ihnen beauftragten Anfragen gehören. Eine etwaige Schwachstellenuntersuchung kann in einem geeigneten, gesondert geklärten Geltungsbereich fortgesetzt werden.

Wie prüfen Sie die Grenzen ohne Tests öffentlicher Systeme?

Führen Sie ein Planspiel mit synthetischen Inventareinträgen und einer Testwarteschlange ohne Netzwerkzugriff durch. Sie brauchen Nachweise für Entscheidungen und Unterbrechungen, bevor echte externe Ziele ins Spiel kommen.

In dieser vorgeschlagenen Übung übernimmt ein Teammitglied die Prüferrolle, ein anderes die Verantwortung für den Dienst. Lassen Sie beide mit den Unterlagen arbeiten, die Ihr Team tatsächlich verwendet. Ergänzen Sie fehlende Angaben nicht mündlich, sondern notieren Sie, wo die Beteiligten eine Antwort erfinden müssen.

Wechseln Sie den Betreiber. Beginnen Sie mit einer freigegebenen fiktiven Anwendung und ändern Sie deren Eintrag anschließend auf einen vom Anbieter gehosteten Mandanten. Prüfen Sie, ob die bestehende Erlaubnis diese Beziehung abdeckt. Die Übung ist bestanden, wenn das Team entweder die einschlägige Erlaubnis nachweist oder das neue Ziel bis zur Klärung zurückstellt.

Entfernen Sie eingereihte Arbeiten. Nehmen Sie ein synthetisches Ziel in die Testwarteschlange auf und entziehen Sie ihm anschließend die Freigabe. Prüfen Sie ausstehende Aufträge und Wiederholungsversuche ebenso wie die nächste geplante Systemerkennung. Halten Sie fest, welcher Mechanismus die Ausführung der zurückgezogenen Arbeiten verhindert.

Verlassen Sie die freigegebene Anwendung. Ergänzen Sie eine synthetische Weiterleitung zu einem anderen Beispiel-Hostnamen. Fragen Sie, was der Prüfer als Nächstes tut und wo diese Entscheidung dokumentiert wird. Die Antwort sollte sich nach den Auftragsgrenzen richten, nicht danach, wer gerade zusieht.

Nehmen Sie eine Betreiberbeschwerde entgegen. Versenden Sie intern eine Beispielmeldung mit fiktivem Zeitstempel und einer Anfragekennung. Prüfen Sie, ob das empfangende Team den Prüfungsverantwortlichen findet, die richtigen Arbeiten unterbrechen und verständlich antworten kann, ohne sensibles Material offenzulegen.

Leiten Sie aus Fehlern konkrete Änderungen ab: einen fehlenden Verantwortlichen ergänzen, einen Ausschluss auf Wiederholungsversuche ausweiten oder ein Meldeformular korrigieren, das Beschwerden an die falsche Warteschlange weiterleitet. Wiederholen Sie anschließend das betroffene Szenario. Erfolg bedeutet, dass Ihre Reaktion auf diese Fälle nachweislich funktioniert. Es beweist nicht, dass jeder denkbare Fehler bei der Zielauswahl ausgeschlossen ist.

Welche Fragen zur Scan-Erlaubnis führen häufig zu Unklarheiten?

Technische Zuordnung, Kontaktdaten und Erlaubnis beantworten unterschiedliche Fragen. Machen Sie diese Unterschiede deutlich, wenn jemand einen Scan erweitern möchte.

Gehört das Ziel eines CNAME zum Geltungsbereich?

Ein CNAME belegt eine DNS-Beziehung. Er beantwortet nicht, wer das Ziel betreibt oder welche Tests Ihr Auftrag dort erlaubt. Prüfen Sie die Dienstidentität und die einschlägige Erlaubnis, bevor Sie aktive Tests erweitern. Eine gültige bestehende Vereinbarung kann das Ziel abdecken. Der Alias allein belegt diese Vereinbarung nicht.

Erlaubt eine öffentliche Offenlegungsrichtlinie jeden Test?

Lesen Sie den tatsächlichen Geltungsbereich und die Bedingungen. Eine Einladung zur Meldung ist hilfreich, doch die veröffentlichten Bestimmungen können Systeme, Konten, Verfahren oder den Umgang mit Daten begrenzen. Klären Sie unklare Grenzen vor aktiven Tests mit dem Programmkontakt. Unser Leitfaden zur Programmkonfiguration erklärt, wie Sie diese Grenzen in Kit veröffentlichen.

Muss jeder Anbieter jede Prüfung einzeln genehmigen?

Es gibt keinen einheitlichen Freigabeprozess für alle Anbieter. Prüfen Sie die aktuelle Richtlinie für den betreffenden Dienst und die vorgesehenen Arbeiten. Manche Tests sind durch veröffentlichte Bedingungen abgedeckt, andere erfordern eine gesonderte Vereinbarung. Bewahren Sie Ihre Entscheidungsgrundlage auf, damit der nächste Prüfer sie nicht anhand einer allgemeinen Anbieter-Startseite rekonstruieren muss.

Wie unterstützt Kit klare Testgrenzen und Meldewege?

Ihr Team braucht eine verständliche öffentliche Richtlinie und einen verlässlichen Ort für Fragen dazu. Der Scanner benötigt außerdem eigene, korrekt umgesetzte Kontrollen für die Ausführung.

Das VDP-Portal von Kit veröffentlicht Ziele innerhalb des Geltungsbereichs, Kategorien außerhalb des Geltungsbereichs, ausgeschlossene Schwachstellentypen und den Text Ihrer Offenlegungsrichtlinie. Es kann die Safe-Harbor-Formulierung Ihres Programms anzeigen und Forscherinnen und Forschern ermöglichen, den Geltungsbereich als Markdown zu kopieren. Erläutern Sie dort die erlaubten Dienstgrenzen und den Kontakt bei Unklarheiten.

Das Forscherportal bietet einen Weg, Meldungen einzureichen und weiterzuverfolgen. Geben Sie den Bearbeitern dieser Meldungen einen direkten Kontakt zu den Verantwortlichen für Prüfungen, die Ihr Unternehmen beauftragt. Eine Meldung über unerwünschte Anfragen sollte jemanden erreichen, der ihre Quelle untersuchen und eine Unterbrechung koordinieren kann.

Das Veröffentlichen eines Geltungsbereichs in Kit verifiziert weder die Eigentumsverhältnisse der Infrastruktur noch erteilt es eine Erlaubnis für Tests bei Dritten. Es konfiguriert auch nicht Ihren Scanner und storniert keine eingereihten Aufträge. Die Einstellungen zum Geltungsbereich weisen Meldungen außerhalb der veröffentlichten Grenzen zudem nicht automatisch zurück. Dafür bleiben die zuständigen Personen und Werkzeuge erforderlich.

Verbinden Sie vor Ihrer nächsten Prüfung den veröffentlichten Geltungsbereich, den Erlaubnisnachweis, die Ausführungskonfiguration und den Kontakt für Unterbrechungen. Prüfen Sie eine synthetische Zieländerung über den gesamten Ablauf hinweg. Das gewünschte Ergebnis ist einfach: Ihr Team kann erklären, warum ein Test laufen darf, und ihn stoppen, sobald diese Erklärung nicht mehr trägt.