Schwachstellenscanner sind gut in dem, was sie tun. Sie werden die ungepatchte Apache-Instanz, den offenen S3-Bucket und die falsch konfigurierte TLS-Verschlüsselungssuite finden. Sie durchsuchen Ihre Angriffsfläche, gleichen CVEs ab, bewerten den Schweregrad und reichen Tickets ein.
Aber sie alle haben den gleichen blinden Fleck: Sie scannen die von Ihnen kontrollierte Infrastruktur. Sobald ein Risiko in einem System entsteht, das jemand anderem gehört, muss Ihr Scanner nichts untersuchen. Kein Ziel, kein Fund, kein Ticket.
Dabei handelt es sich nicht um eine Funktionslücke bei irgendeinem Produkt. Es handelt sich um eine strukturelle Einschränkung der Funktionsweise des Scannens. Ein Scanner benötigt einen Host, einen Port, ein Zertifikat, eine Codebasis. Verfügbarkeits- und Vertrauensausfälle Dritter stellen sich nicht so dar. Sie zeigen sich als Verhaltensanomalien bei Diensten, die Ihr Unternehmen nutzt, aber nicht instrumentieren kann.
Hier sind fünf Kategorien von Risiken durch Dritte aufgeführt, die völlig außerhalb des Sichtfelds des Scanners liegen.
Anbieter-DNS-Hijacking und Subdomain-Übernahme
Ihr Scanner überprüft Ihre DNS-Einträge. Möglicherweise werden fehlende CNAMEs angezeigt, die auf deprovisionierte Cloud-Ressourcen verweisen. Gut. Aber das DNS Ihres Zahlungsabwicklers? Die Subdomain Ihres Identitätsanbieters? Die Origin-Pull-Domain Ihres CDN? Diese sind nicht im Geltungsbereich.
Ein DNS-Hijacking gegen einen Anbieter, von dem Sie abhängig sind, löst Ihren Scanner nicht aus, weil die Domain nicht Ihnen gehört. Der Angreifer übernimmt auth.vendor.com, richtet eine Seite zum Sammeln von Anmeldeinformationen ein und Ihre SSO-Integration leitet Benutzer problemlos dorthin weiter. Aus Sicht Ihrer Infrastruktur hat sich nichts geändert. Der CNAME wird weiterhin aufgelöst. Der TLS-Handshake ist abgeschlossen (der Angreifer stellt über eine ACME-Challenge ein Zertifikat für die gekaperte Domäne bereit). Ihre Protokolle zeigen erfolgreiche Weiterleitungen.
Das Erkennungsfenster beträgt hier Minuten, nicht Tage. Wenn Sie die DNS-Auflösungskette für Ihre kritischen Endpunkte von Drittanbietern, einschließlich CNAME-Ziele, NS-Delegierungen und SOA-Einträge, nicht überwachen, verlassen Sie sich vollständig darauf, dass der Anbieter dies zuerst bemerkt.
Was tatsächlich funktioniert: Kontinuierliche DNS-Eintragsüberwachung anhand einer bekanntermaßen guten Baseline für jede Drittanbieterdomäne, in die Ihre Anwendung integriert ist. Wenn auth.vendor.com plötzlich auf eine neue IP umsteigt oder sich seine NS-Einträge ändern, ist das ein Signal, für das es sich lohnt, jemanden zu wecken. Die wichtigsten Datensatztypen sind A/AAAA, CNAME-Ziele, NS-Delegierungen und SOA-Serien. Jede unerwartete Änderung dieser Werte ist eine Warnung wert.
Der Ablauf von Zertifikaten Dritter greift in Ihre Authentifizierungskette ein
Ihr Scanner überprüft Ihre Zertifikate. Es weiß, wann api.yourcompany.com in 30 Tagen abläuft und reicht das Verlängerungsticket ein. Aber das Zertifikat auf login.identityprovider.com? Auf api.paidgateway.io? Auf dem CDN-Edge-Knoten, der Ihr kundenorientiertes JavaScript-Paket bereitstellt?
Wenn ein Drittanbieterzertifikat abläuft, ist der Fehlermodus trügerisch. Ihre Systeme haben sich nicht geändert. Ihre Überwachung stellt fest, dass Ihre Endpunkte Fehler zurückgeben, aber die Hauptursache ist ein abgelaufenes Zertifikat drei Hops weiter oben in einem Dienst, der Ihnen nicht gehört. Schlimmer noch, einige Fehlermodi sind partiell: Mobile Clients mit strengerer Zertifikatsfestlegung schlagen fehl, während Desktop-Browser beim Durchklicken eingeschränkte Warnungen anzeigen.
Dies passierte einem großen Identitätsanbieter im Jahr 2024. Sein Zwischenzertifikat lief an einem Samstag ab. Jede nachgelagerte SaaS-Anwendung, die auf ihren OIDC-Flow angewiesen war, begann, 502-Fehler an Endbenutzer zurückzugeben. Die eigenen Scanner der SaaS-Anbieter zeigten Grün. Ihre eigenen Zertifikate waren in Ordnung. Die Scanner hatten keine Vorstellung von „dem Zertifikat am anderen Ende meines HTTPS-Anrufs an den IDP“. Incident-Response-Teams verbrachten Stunden damit, 502-Fehler über ihre eigenen Load Balancer und Anwendungscodes zu verfolgen, bevor jemand auf die Idee kam, die Upstream-Zertifikatskette zu überprüfen.
Die Lösung besteht darin, den Zertifikatsablauf für jeden TLS-Endpunkt in Ihrer Abhängigkeitskette zu überwachen, nicht nur für Ihren eigenen. Überwachen Sie das Blattzertifikat, die Zwischenprodukte und das Stammzertifikat. Alarmieren Sie nach 14 Tagen, nicht nach 7. Und verfolgen Sie den Ablauf der Zwischenzertifizierungsstelle separat, denn das ist der Punkt, den die Anbieter selbst vergessen.
Verschlechterung des Zahlungs- und Authentifizierungsanbieters, die 200 OK
zurückgibt Dieser ist subtil und teuer.
Ihre Verfügbarkeitsprüfungen senden eine Anfrage an api.paidprovider.com/v1/health. Sie erhalten eine 200 zurück. Grün. Aber hinter diesem Gesundheitsendpunkt wird die Transaktionsverarbeitungswarteschlange des Anbieters um 40 Sekunden gesichert. Echte Gebühren laufen ab. Ihr Checkout-Ablauf funktioniert technisch gesehen: Er sendet die Anfrage, erhält (irgendwann) eine Antwort und die Antwort lautet „ausstehend“. Ihr Scanner sieht eine 200. Ihr synthetischer Monitor sieht eine 200. Ihre Benutzer sehen 45 Sekunden lang ein sich drehendes Rad und brechen den Kauf ab.
Schwachstellenscanner können dies grundsätzlich nicht abbilden. Sie testen die binäre Erreichbarkeit: Kann ich eine Verbindung herstellen, antwortet der Dienst mit einem Nicht-Fehlercode? Eine verminderte Leistung Dritter stellt jedoch ein Risiko für Ihr Unternehmen dar, das sich eher in einem Verlust als in einem Verstoß äußert. Umsatzeinbußen, Verlust des Benutzervertrauens und SLA-Verletzungen gegenüber Ihren eigenen Kunden, die eine Kaufabwicklung in weniger als einer Sekunde erwarten.
Um dies zu erkennen, müssen die Reaktionszeit und die Semantik des Antwortkörpers anhand von Endpunkten Dritter unter realen Bedingungen gemessen werden. Nicht „Ist es in Ordnung“, sondern „Funktioniert es innerhalb der von meiner Anwendung vorausgesetzten Grenzen?“ Wenn Ihre Zahlungs-API in der Vergangenheit innerhalb von 400 ms reagiert hat und es heute nur 12 Sekunden dauert, handelt es sich um einen Betriebsvorfall, unabhängig davon, ob der Statuscode 200 lautet oder nicht.
Vorfälle auf der Lieferantenstatusseite, die Ihr SOC nie liest
Jeder große SaaS-Anbieter veröffentlicht eine Statusseite. AWS hat eines. Okta hat einen. Cloudflare, Stripe, Datadog, PagerDuty. Sie veröffentlichen Vorfälle, markieren Komponenten als beschädigt und veröffentlichen (schließlich) Obduktionen.
Fast kein SOC hat diese in seiner Überwachungsschleife.
Die Informationen sind öffentlich, maschinenlesbar (die meisten stellen JSON- oder RSS-Feeds bereit) und sind für die Risikolage Ihrer Umgebung direkt relevant. Wenn der Anbieter Ihres Rundholzverladers meldet: „Ingest-Pipeline in USA-Ost beeinträchtigt“, erklärt das die Lücke in Ihrem SIEM. Wenn Ihr Authentifizierungsanbieter „Erhöhte Fehlerraten am /authorize-Endpunkt“ meldet, ist das die Hauptursache für die 4xx-Spitze, die Ihre eigene Warnung gerade ausgelöst hat.
Die Lücke ist organisatorischer und nicht technischer Natur. Sicherheitsteams schauen sich die Statusseiten nicht an, weil es sich wie ein operatives Problem anfühlt. Ops-Teams achten vielleicht auf ihre Top-2-3-Anbieter, aber nicht auf den Long Tail. Das Ergebnis: Ihr SOC verbringt 30 Minuten damit, eine Protokolllücke zu untersuchen, die der Anbieter 20 Minuten zuvor angekündigt hatte, als Sie sie bemerkten.
Die Operationalisierung ist unkompliziert. Abonnieren Sie die Statusseiten-Feeds aller Anbieter in Ihrer Lieferkette. Nehmen Sie Vorfälle in Ihre Alarmierungspipeline auf. Korrelieren Sie eingehende Lieferantenvorfälle mit Ihrem eigenen Warnzeitplan. Dies ist kein Scan. Es handelt sich um eine Abonnement- und Korrelationsmaschine.
Geplante Sicherheitsjobs, die stillschweigend gegen einen Anbieterendpunkt fehlschlagen
Ihr Backup-Agent überträgt alle 6 Stunden verschlüsselte Snapshots an einen Cloud-Speicherendpunkt. Ihr Protokollversender leitet die Daten an die Ingest-API Ihres SIEM-Anbieters weiter. Ihr Schwachstellenscanner selbst meldet Ergebnisse an eine zentrale SaaS-Konsole. Ihr Bot zur Zertifikatserneuerung ruft die API des ACME-Anbieters auf.
Dabei handelt es sich allesamt um geplante Jobs, die davon abhängen, dass ein Endpunkt eines Drittanbieters erreichbar und funktionsfähig ist. Wenn dieser Endpunkt ausfällt, schlägt der Job stillschweigend fehl. Kein Schnappschuss hochgeladen. Keine Protokolle weitergeleitet. Es wurden keine Scanergebnisse gemeldet. Kein Zertifikat erneuert.
Die Auswirkungen auf die Sicherheit verstärken sich mit der Zeit. Wenn Sie ein Backup-Fenster verpassen, ist wahrscheinlich alles in Ordnung. Sie haben eine Woche verpasst, weil der Speicheranbieter stillschweigend eine API-Version eingestellt hat und die Anfragen Ihres Agenten 403 zurückgegeben haben? Jetzt ist Ihr RPO kaputt und niemand weiß es bis zum Wiederherstellungstest (wenn Sie Wiederherstellungstests ausführen). Ihr Compliance-Status setzt eine kontinuierliche Sicherung voraus. Die Realität ist eine wochenlange Lücke, die nur während der Prüfung oder, schlimmer noch, während eines tatsächlichen Wiederherstellungsszenarios zu Tage tritt.
Um stille Jobfehler zu erkennen, müssen die Ausgabeartefakte des Jobs überwacht werden, nicht nur der Jobprozess. Ist der Schnappschuss tatsächlich gelandet? Hat der Bestimmungsort des Rundholzversenders den Empfang bestätigt? Hat die Zertifikatserneuerung eine neue Zertifikatsdatei mit einem aktualisierten Ablaufdatum erstellt? Wenn die Antwort „Wir überprüfen den Exit-Code des Jobs“ lautet, reicht das nicht aus. Ein Job kann 0 beenden und trotzdem nichts erreicht haben, wenn der Remote-Endpunkt die Nutzlast mit einer 200-stufigen Antwort und einem Fehlertext abgelehnt hat.
Operationalisierung der Risikoüberwachung durch Dritte
Das Muster bei allen fünf Risiken ist das gleiche: Ihr Scanner kann nicht finden, was er nicht erreichen kann, und er kann keine Systeme erreichen, die Ihnen nicht gehören.
Um diese Lücken zu schließen, ist eine andere Klasse von Instrumenten erforderlich. Kein Scannen, sondern kontinuierliche externe Überwachung der Dienste, auf die Sie angewiesen sind. DNS-Auflösungsketten, TLS-Zertifikate auf Upstream-Endpunkten, Antwortlatenz und Body-Validierung gegen APIs von Drittanbietern, Statusseiten-Feeds und synthetische Prüfungen, die bestätigen, dass geplante Jobs die erwartete Ausgabe erbracht haben.
Sie können dies selbst mit einer Kombination aus skriptgesteuerten Prüfungen, Cron-Jobs und Alarmweiterleitung zusammenstellen. Einige Teams tun es. Die Komplexität liegt nicht in einer einzelnen Prüfung. Es geht darum, die Abdeckung aufrechtzuerhalten, während Ihre Anbieterliste wächst, und Signale zwischen den Anbietern zu korrelieren.
Tools wieDevHelmBehandeln Sie dies als ein erstklassiges Problem: Überwachen Sie die externen Dienste, von denen Ihre Anwendung abhängt, benachrichtigen Sie sie, wenn sich ihr Verhalten ändert, und geben Sie Ihrem SOC die Korrelation zwischen „Anbieter X herabgestuft“ und „unsere eigenen Warnungen wurden 3 Minuten später ausgelöst“. Unabhängig davon, ob Sie es bauen oder kaufen, ist der architektonische Aspekt derselbe: Die Risikoüberwachung durch Dritte ist eine andere Funktion als das Scannen von Schwachstellen. Es gehört in Ihr Sicherheitsprogramm, kommt aber nicht von Ihrem Scanner.
Die Lücke ist strukturell und nicht zufällig
Schwachstellenscanner sind nicht kaputt. Sie beziehen sich auf ein anderes Problem. Sie finden Schwachstellen in den von Ihnen kontrollierten Systemen, sodass Sie diese beheben können, bevor ein Angreifer sie ausnutzt. Das ist wertvoll und notwendig.
Ihre tatsächliche Risikooberfläche umfasst jedoch jedes externe System, dem Ihre Anwendung vertraut. Jede DNS-Delegation, jedes Upstream-TLS-Zertifikat, jede Zahlungs-API, jede Statusseite, jeder Cloud-Endpunkt, von dem Ihre Cron-Jobs abhängen. Dabei handelt es sich um Vertrauensbeziehungen, und Vertrauensbeziehungen verschlechtern sich auf eine Weise, die nicht zu CVEs führt.
Wenn Ihr Sicherheitsprogramm nur das instrumentiert, was es besitzt, ist es für die Hälfte der Fehlermodi, die Ihre Benutzer tatsächlich treffen, blind. Die fünf oben genannten Risiken sind nicht exotisch. Sie finden wöchentlich in der gesamten Branche statt. Die Frage ist, ob Ihr Team es durch eigene Überwachung oder durch ein Kundensupport-Ticket 45 Minuten später herausfindet.