Seien wir ehrlich: Die meisten Unternehmen behandeln Sicherheit wie eine jährliche Untersuchung. Sie beauftragen eine Firma, die verbringt zwei Wochen damit, Ihr Netzwerk zu untersuchen, sie händigt Ihnen ein riesiges PDF voller "kritischer" und "hoher" Funde aus, Ihr Team schwitzt einen Monat lang durch den Behebungsprozess, und dann atmen Sie erleichtert auf. Sie sind "sicher".
Aber hier ist das Problem. In dem Moment, in dem der Berater seinen Laptop zuklappt und die Schlussrechnung sendet, beginnt Ihre Sicherheitslage zu verfallen.
Jemand in DevOps schiebt einen neuen API-Endpunkt in die Produktion, der sich nicht hinter der Firewall befindet. Ein Marketing-Praktikant richtet eine temporäre WordPress-Seite auf einem vergessenen Subnetz ein, um eine Landingpage zu testen. Ein Cloud-Engineer konfiguriert einen S3-Bucket falsch und macht ihn versehentlich öffentlich. In der Welt der modernen Cloud-Infrastruktur ist Ihr Netzwerk keine statische Festung; es ist eher wie ein lebender Organismus, der jede einzelne Stunde wächst und sich verändert.
Wenn Sie Ihre Angriffsfläche nur einmal im Jahr kartieren, sichern Sie Ihr Unternehmen nicht wirklich ab – Sie erstellen lediglich eine Momentaufnahme eines Augenblicks, der nicht mehr existiert. Diese "Point-in-Time"-Sicherheit ist genau die Art und Weise, wie Datenpannen passieren. Hacker warten nicht auf Ihr jährliches Audit. Sie verwenden automatisierte Tools, um den einen vergessenen, ungepatchten Server zu finden, von dem Sie nicht einmal wussten, dass er noch läuft.
Die Verhinderung dieser Sicherheitsverletzungen erfordert ein Umdenken. Sie müssen von periodischen Audits zu kontinuierlicher Angriffsflächenkartierung übergehen. Es ist der Unterschied zwischen dem jährlichen Überprüfen Ihrer Schlösser und dem Besitz eines intelligenten Sicherheitssystems, das Sie alarmiert, sobald ein Fenster offen gelassen wird.
Was genau ist Angriffsflächenkartierung?
Bevor wir uns mit dem "kontinuierlichen" Teil befassen, müssen wir uns darüber im Klaren sein, was die "Angriffsfläche" eigentlich ist. Vereinfacht ausgedrückt ist Ihre Angriffsfläche die Summe aller verschiedenen Punkte, an denen ein unbefugter Benutzer (ein Angreifer) versuchen kann, in Ihr System einzudringen oder Daten zu extrahieren.
Stellen Sie es sich als jede einzelne "Tür" und jedes "Fenster" in Ihre digitale Umgebung vor. Dazu gehören Dinge, von denen Sie wissen – wie Ihre Hauptwebsite und Ihr Kundenportal – und Dinge, die Sie wahrscheinlich vergessen haben.
Die drei Arten von Angriffsflächen
Um Ihre Oberfläche effektiv zu kartieren, müssen Sie sie aus drei verschiedenen Blickwinkeln betrachten:
1. Die digitale Angriffsfläche Das ist es, woran die meisten Menschen denken, wenn sie über Cybersicherheit sprechen. Sie umfasst alles, was über das Internet oder ein Netzwerk zugänglich ist.
- Webanwendungen: Ihre Hauptseite, Admin-Panels und versteckte Staging-Umgebungen.
- APIs: Der "Klebstoff", der Ihre Apps verbindet. Diese werden oft übersehen und haben häufig keine ordnungsgemäße Authentifizierung.
- Cloud-Speicher: S3-Buckets, Azure Blobs und Google Cloud Storage.
- Netzwerkports: Offene Ports (wie SSH oder RDP), die geschlossen sein sollten, aber nicht sind.
- DNS-Einträge: Subdomains, die möglicherweise auf alte, ungepatchte Versionen Ihrer App verweisen.
2. Die physische Angriffsfläche Während wir uns hier auf die Cloud konzentrieren, können wir die physische Seite nicht ignorieren. Dazu gehören USB-Anschlüsse an Bürocomputern, ungesicherte Serverräume und sogar die Laptops, die Ihre Mitarbeiter in Cafés mitnehmen. Wenn ein böswilliger Akteur etwas in Ihre Hardware einstecken kann, sind sie drin.
3. Die menschliche Angriffsfläche (die "soziale" Oberfläche) Ihre Mitarbeiter sind oft der einfachste Weg in ein Netzwerk. Phishing, Social Engineering und der Diebstahl von Anmeldeinformationen sind die wichtigsten Möglichkeiten, wie Angreifer teure Firewalls umgehen. Während die Kartierung schwieriger ist (da Sie keinen Menschen "scannen" können), beinhaltet sie die Identifizierung, wer Zugriff auf hoher Ebene hat und wie diese Personen angegriffen werden.
Warum traditionelle Kartierung fehlschlägt
Jahrelang war der Standard das "manuelle Asset-Inventar". Eine Tabelle, in der ein IT-Manager jeden Server, jede IP-Adresse und jede Anwendung auflistete.
Das Problem? Tabellenkalkulationen sind tot, sobald sie gespeichert werden. In einer Cloud-nativen Umgebung mit AWS, Azure oder GCP sind Ressourcen kurzlebig. Container werden in Sekundenschnelle hoch- und heruntergefahren. Täglich werden neue Microservices bereitgestellt. Wenn Ihre Karte eine Tabelle ist, fliegen Sie blind.
Hier kommt die kontinuierliche Angriffsflächenkartierung ins Spiel. Anstelle einer Liste ist es ein automatisierter Prozess, der ständig nach Ihren Assets sucht, identifiziert, was sie sind, und sie in Echtzeit auf Schwachstellen überprüft.
Die Gefahr der "Point-in-Time"-Sicherheit
Wenn Sie sich derzeit auf einen jährlichen Penetration Test verlassen, spielen Sie im Wesentlichen ein Spiel von "Ich hoffe, nichts geht kaputt" für 364 Tage im Jahr. Das nennen wir "Point-in-Time"-Sicherheit.
Hier ist ein realistisches Szenario, wie dies fehlschlägt:
15. Januar: Sie beauftragen eine Boutique-Sicherheitsfirma. Sie führen einen gründlichen manuellen Penetration Test durch. Sie finden drei Schwachstellen. Ihr Team behebt sie sofort. Sie erhalten einen "Sauber"-Bericht. Sie fühlen sich großartig.
10. Februar: Ein Entwickler erstellt eine "Test"-Umgebung, um eine neue Funktion auszuprobieren. Um die Dinge zu vereinfachen, deaktivieren sie die Authentifizierung für eine der APIs. Sie vergessen, diese Umgebung nach dem Test zu löschen.
2. März: Für eine Bibliothek, die Sie in Ihrer Hauptanwendung verwenden, wird eine neue CVE (Common Vulnerabilities and Exposures) veröffentlicht. Es ist ein kritischer Remote Code Execution (RCE)-Bug.
12. April: Ein Angreifer, der einen automatisierten Scanner verwendet, findet die vergessene API vom 10. Februar. Sie springen von dieser Testumgebung in Ihr Hauptproduktionsnetzwerk. Mit der CVE vom 2. März erhöhen sie ihre Berechtigungen und extrahieren Ihre gesamte Kundendatenbank.
15. Januar (nächstes Jahr): Ihre Pen Tester kommen zurück und sagen Ihnen, dass Sie vor neun Monaten gehackt wurden.
Die Lücke zwischen der "Momentaufnahme" und der aktuellen Realität ist der Ort, an dem die Sicherheitsverletzung stattfindet. Bis Sie erkennen, dass ein Loch im Zaun war, ist der Eindringling bereits in das Haus eingedrungen und hat die Möbel umgestellt.
Auf dem Weg zum Continuous Threat Exposure Management (CTEM)
Um dies zu beheben, bewegt sich die Branche in Richtung Continuous Threat Exposure Management (CTEM). Bei CTEM geht es nicht nur um das Scannen; es ist ein Fünf-Stufen-Zyklus:
- Scoping: Definieren, was Sie tatsächlich schützen müssen.
- Discovery: Auffinden jedes Assets (bekannt und unbekannt).
- Priorisierung: Entscheiden, welche Löcher tatsächlich gefährlich sind und welche nur Rauschen sind.
- Validation: Testen, ob eine Schwachstelle tatsächlich ausgenutzt werden kann.
- Mobilization: Schnelles Bereitstellen der Korrektur.
Wenn Sie diesen Zyklus automatisieren, hören Sie auf, auf Verstöße zu reagieren, und beginnen, diese zu verhindern. Dies ist die Kernphilosophie hinter Plattformen wie Penetrify. Anstatt auf ein manuelles Audit zu warten, bietet Penetrify On-Demand Security Testing (ODST) und verwandelt Ihre Sicherheitslage effektiv von einem statischen Bild in einen Live-Video-Feed.
Wie Continuous Attack Surface Mapping tatsächlich funktioniert
Wenn Sie sich fragen, wie "automatisiertes Mapping" tatsächlich unter der Haube aussieht, ist es nicht nur ein Tool, das einen Scan durchführt. Es ist eine Reihe von geschichteten Prozessen, die nachahmen, wie ein echter Angreifer denkt.
Schritt 1: Reconnaissance (Die "Outside-In"-Ansicht)
Ein Angreifer beginnt nicht damit, Ihre Firewall anzugreifen; er beginnt damit, zu sehen, was sichtbar ist. Kontinuierliche Mapping-Tools tun dasselbe. Sie verwenden Techniken wie:
- DNS Enumeration: Finden aller Ihrer Subdomains (z. B.
dev.company.com,vpn.company.com,api-test.company.com). - IP Space Scanning: Überprüfen registrierter IP-Bereiche, um zu sehen, was tatsächlich antwortet.
- WHOIS- und SSL-Zertifikatsanalyse: Untersuchen von Zertifikaten, um zugehörige Domains oder versteckte Dienste zu finden.
- Suchmaschinen-Dorking: Verwenden von Google oder Shodan, um indizierte Seiten zu finden, die nicht öffentlich sein sollten.
Schritt 2: Asset-Identifizierung und -Klassifizierung
Sobald das Tool eine IP-Adresse oder eine Domain gefunden hat, muss es herausfinden, was es ist. Ist es ein Linux-Server, auf dem Nginx läuft? Ist es ein Legacy-Windows-2012-Server? Ist es ein Load Balancer?
Das Mapping-Tool "fingerprintet" den Dienst. Es betrachtet die Header, die Antwortzeiten und die offenen Ports, um das Asset zu kategorisieren. Dies ist entscheidend, da Sie eine öffentliche Marketingseite nicht genauso behandeln wie eine Datenbank, die PCI-Daten enthält.
Schritt 3: Schwachstellenanalyse
Nun, da das Tool weiß, was das Asset ist, sucht es nach Löchern. Dies beinhaltet:
- Versionsprüfung: Vergleichen der Softwareversion mit Datenbanken bekannter CVEs.
- Konfigurationsaudits: Überprüfen auf Standardpasswörter (wie
admin/admin) oder offene Verzeichnisse. - Web Scanning: Testen auf die OWASP Top 10, wie z. B. SQL Injection, Cross-Site Scripting (XSS) und Broken Access Control.
Schritt 4: Analyse des Angriffspfads
Dies ist der anspruchsvollste Teil. Eine Schwachstelle isoliert betrachtet, könnte "Medium" sein. Aber wenn diese Schwachstelle es einem Angreifer ermöglicht, eine "High"-Schwachstelle auf einem anderen Server zu erreichen, ist das Gesamtrisiko "Critical".
Kontinuierliche Mapping-Tools visualisieren diese Pfade. Sie zeigen Ihnen: "Wenn ein Angreifer diese vergessene API trifft, kann er ein Token stehlen, mit dem er auf die AWS-Konsole zugreifen kann, mit der er die Produktionsdatenbank herunterladen kann."
Praktische Strategien für das Management Ihrer Angriffsfläche
Sie benötigen kein Millionen-Dollar-Budget, um mit der Verbesserung Ihres Attack Surface Management zu beginnen. Egal, ob Sie ein Einzelgründer oder ein CTO in einem mittelständischen Unternehmen sind, hier sind die konkreten Schritte, die Sie unternehmen sollten.
1. Überprüfen Sie Ihre DNS und Subdomains
Ich kann es nicht oft genug betonen: Überprüfen Sie Ihre DNS-Einträge. Die meisten Verstöße beginnen mit einer "vergessenen" Subdomain.
Die Checkliste:
- Listen Sie alle aktiven Subdomains auf.
- Identifizieren Sie alle "dev"-, "test"- oder "staging"-Umgebungen, die öffentlich sind.
- Überprüfen Sie auf "dangling DNS" (CNAME-Einträge, die auf Dienste verweisen, die Sie nicht mehr verwenden, wie z. B. eine alte Heroku-App oder ein nicht mehr existierender S3-Bucket). Angreifer können diese alten Namen beanspruchen und ihre eigenen bösartigen Inhalte auf Ihrer Domain hosten.
- Implementieren Sie eine strenge Namenskonvention für neue Umgebungen, damit diese leichter zu verfolgen sind.
2. Straffen Sie Ihre Cloud-Berechtigungen
In der Cloud umfasst Ihre "Angriffsfläche" Ihre Identity and Access Management (IAM)-Rollen. Wenn jeder Entwickler AdministratorAccess für Ihr AWS-Konto hat, ist Ihre Angriffsfläche riesig.
Die Strategie:
- Principle of Least Privilege (PoLP): Geben Sie den Mitarbeitern genau das, was sie für ihre Arbeit benötigen, und nichts weiter.
- MFA Everything: Wenn ein Dienst Multi-Factor Authentication haben kann, muss er sie haben. Keine Ausnahmen.
- Audit S3/Blob Permissions: Verwenden Sie automatisierte Tools, um sicherzustellen, dass keine Storage Buckets auf "Public" gesetzt sind, es sei denn, sie sollen speziell öffentliche Bilder für Ihre Website enthalten.
3. Inventarisieren Sie Ihre APIs
APIs sind die "unsichtbare" Angriffsfläche. Da sie keine traditionelle Benutzeroberfläche haben, vergessen Entwickler oft, ihnen die gleiche Sicherheitsrigorosität zu verleihen wie dem Frontend.
Worauf Sie achten sollten:
- Shadow APIs: APIs, die von Entwicklern für ein bestimmtes Projekt erstellt wurden, die nie dokumentiert oder offiziell "veröffentlicht" wurden.
- Zombie APIs: Alte Versionen von APIs (v1, v2), die noch ausgeführt werden, weil ein alter Client sie noch verwendet, aber ihnen die Sicherheitsupdates von v3 fehlen.
- Mangelnde Ratenbegrenzung: Wenn eine API keine Ratenbegrenzung hat, kann ein Angreifer Passwörter per Brute-Force-Angriff ermitteln oder Ihre gesamte Datenbank in wenigen Minuten auslesen.
4. Automatisieren Sie die "Low-Hanging Fruit"
Sie brauchen keinen Menschen, um Ihnen zu sagen, dass Sie eine veraltete Version von Apache verwenden. Das ist eine Verschwendung menschlicher Talente.
Verwenden Sie automatisierte Scanner für die bekannten Dinge. Dies entlastet Ihr Sicherheitsteam (oder Ihren überarbeiteten Entwickler), damit es sich auf "Logikfehler" konzentrieren kann – die Art von Fehlern, die die Automatisierung nicht finden kann, wie z. B. ein Fehler in der Art und Weise, wie Ihre App Passwort-Rücksetzungen handhabt.
Häufige Fehler im Attack Surface Management
Selbst Unternehmen, die glauben, dass sie es richtig machen, tappen oft in einige klassische Fallen. Wenn Sie diese Muster in Ihrem Unternehmen erkennen, ist es an der Zeit, den Kurs zu ändern.
Fehler 1: Verwechslung von "Scanning" mit "Mapping"
Ein Schwachstellen-Scanner (wie Nessus oder OpenVAS) sagt Ihnen, was mit einem bestimmten Ziel nicht stimmt. Eine Attack Surface Map sagt Ihnen, was die Ziele überhaupt sind.
Wenn Sie Scans nur auf den IP-Adressen durchführen, die Sie kennen, ignorieren Sie die "Shadow IT" – die Server und Apps, die ohne Wissen der IT-Abteilung eingerichtet wurden. Sie können nicht scannen, was Sie nicht entdeckt haben.
Fehler 2: Die "Alert Fatigue"-Falle
Wenn Sie zum ersten Mal mit dem Continuous Mapping beginnen, werden Sie überfordert sein. Sie werden 400 "Medium"-Schwachstellen und 20 "Low"-Schwachstellen finden. Die meisten Teams geraten in Panik und versuchen, alles auf einmal zu beheben, oder schlimmer noch, sie ignorieren die Warnungen ganz.
Die Lösung: Priorisieren Sie basierend auf der Erreichbarkeit. Eine "Critical"-Schwachstelle auf einem Server, der nicht mit dem Internet verbunden ist und keinen Pfad zu sensiblen Daten hat, ist weniger dringend als eine "Medium"-Schwachstelle auf Ihrer Haupt-Login-Seite.
Fehler 3: Die Vernachlässigung der "Dev"- und "Staging"-Umgebungen
Es gibt den gefährlichen Mythos, dass "es nur eine Testumgebung ist, also spielt es keine Rolle, ob sie unsicher ist".
In Wirklichkeit sind Testumgebungen der bevorzugte Einstiegspunkt für Hacker. Sie haben in der Regel:
- Schwächere Passwörter.
- Weniger Überwachung.
- Echte (oder "bereinigte", aber immer noch sensible) Daten.
- Verbindungen zum Produktionsnetzwerk für Bereitstellungszwecke.
Wenn Ihre Testumgebung eine Hintertür zu Ihrer Produktionsumgebung ist, dann ist Ihre Testumgebung Ihre Produktionsumgebung.
Fehler 4: Sich ausschließlich auf interne Tools verlassen
Interne Tools sind großartig, aber sie haben einen "blinden Fleck". Sie sehen Ihr Netzwerk von innen. Um einen Einbruch wirklich zu verhindern, müssen Sie Ihr Netzwerk genau so sehen, wie ein Angreifer es von außen sieht. Diese "Outside-In"-Perspektive zeigt die falsch konfigurierten Firewalls und die geleakten Anmeldeinformationen, die interne Tools oft übersehen.
Vergleich von manuellem Pen Testing vs. Continuous Mapping (PTaaS)
Viele Geschäftsinhaber fragen: "Warum sollte ich für eine kontinuierliche Plattform bezahlen, wenn ich bereits für einen manuellen Pen Test bezahle?"
Es ist keine "entweder/oder"-Situation; es ist ein "sowohl/als auch". Aber es ist wichtig, die verschiedenen Rollen zu verstehen, die sie spielen.
| Funktion | Manuelles Penetration Testing | Continuous Mapping (PTaaS/Penetrify) |
|---|---|---|
| Häufigkeit | Ein- oder zweimal im Jahr | Echtzeit / On-Demand |
| Umfang | Konzentriert sich auf eine bestimmte Menge von Zielen | Dynamisch; entdeckt automatisch neue Ziele |
| Tiefe | Hoch (kann komplexe Logikfehler finden) | Mittel bis Hoch (findet die meisten technischen Fehler) |
| Kosten | Hoch pro Engagement (Unregelmäßige Ausgaben) | Vorhersehbare monatliche/jährliche Kosten |
| Feedback-Schleife | Lang (warten auf den Abschlussbericht) | Kurz (Echtzeit-Benachrichtigungen) |
| Zweck | Compliance, detaillierte Validierung | Risikoreduzierung, ständige Hygiene |
| Ergebnis | Ein statischer PDF-Bericht | Ein Live-Dashboard Ihrer Angriffsfläche |
Stellen Sie sich den manuellen Pen Test als einen Tiefseetauchgang vor: Sie gehen tief und finden Dinge, die an der Oberfläche nicht sichtbar sind. Continuous Mapping ist wie ein Satellitenüberwachungssystem: Es beobachtet alles, die ganze Zeit, und sagt Ihnen im Moment, wenn sich etwas ändert.
Eine Schritt-für-Schritt-Anleitung zur Implementierung einer Attack Surface-Strategie
Wenn Sie heute von Grund auf neu beginnen, ist dies die Roadmap, die ich empfehle.
Phase 1: Discovery (Woche 1-2)
Hören Sie auf zu raten, was Ihnen gehört. Verwenden Sie ein Tool (wie Penetrify), um einen externen Discovery-Scan durchzuführen.
- Finden Sie jede Domain und Subdomain.
- Ordnen Sie jeden offenen Port zu.
- Identifizieren Sie alle Cloud-Buckets.
- Ziel: Erstellen Sie ein "Source of Truth"-Asset-Inventar.
Phase 2: Baseline und Triage (Woche 3-4)
Nachdem Sie nun eine Liste haben, finden Sie heraus, was tatsächlich gefährlich ist.
- Kategorisieren Sie Assets nach Kritikalität (z. B. "Payment Gateway" = Hohe Kritikalität, "Marketing Blog" = Niedrige Kritikalität).
- Führen Sie Ihren ersten Satz von Schwachstellen-Scans aus.
- Filtern Sie das Rauschen heraus. Konzentrieren Sie sich nur auf "Critical"- und "High"-Schwachstellen, die aus dem Internet erreichbar sind.
- Ziel: Eine priorisierte "To-Do"-Liste für Ihre Entwickler.
Phase 3: Behebung und Validierung (Monat 2)
Beheben Sie die Löcher, aber nehmen Sie nicht einfach das Wort des Entwicklers dafür.
- Wenden Sie Patches und Konfigurationsänderungen an.
- Re-scannen Sie sofort, um zu überprüfen, ob die Korrektur funktioniert hat. (Hier glänzen kontinuierliche Plattformen – Sie können auf "Re-Test" klicken und in Sekundenschnelle wissen, ob das Loch geschlossen ist).
- Ziel: Schließen Sie die gefährlichsten Einstiegspunkte.
Phase 4: Integration (Monat 3 und darüber hinaus)
Hören Sie auf, Sicherheit als separates Projekt zu behandeln, und beginnen Sie, sie als Teil des Workflows zu behandeln.
- DevSecOps: Integrieren Sie Ihr Scanning in Ihre CI/CD-Pipeline. Wenn ein Entwickler Code pusht, der einen gefährlichen Port öffnet, sollte der Build fehlschlagen.
- Benachrichtigungen: Richten Sie Slack- oder E-Mail-Benachrichtigungen ein, wenn ein neues Asset entdeckt wird.
- Ziel: Ein Zustand der „kontinuierlichen Sicherheit“, in dem sich die Karte mit der Aktualisierung des Codes aktualisiert.
Die Rolle von Penetrify in diesem Prozess
Genau deshalb haben wir Penetrify entwickelt. Wir haben gesehen, dass zu viele KMUs und Start-ups von dem „jährlichen Audit“-Zyklus erdrückt werden. Entweder zahlen Sie 20.000 US-Dollar für einen manuellen Test, der in einem Monat veraltet ist, oder Sie kaufen einen Basisscanner, der Ihnen 1.000 Warnmeldungen liefert und keine Anleitung zur Behebung gibt.
Penetrify schließt diese Lücke. Wir bieten Penetration Testing as a Service (PTaaS) an.
So hilft Ihnen Penetrify konkret bei der Verwaltung Ihrer Angriffsfläche:
- Automatisierte Recon: Wir bitten Sie nicht um eine Liste von IPs. Wir finden sie. Wir kartieren Ihre externe Oberfläche genau wie ein Hacker, sodass es keine „Überraschungen“ gibt.
- Cloud-Native Skalierung: Egal, ob Sie auf AWS, Azure oder GCP arbeiten, Penetrify skaliert mit Ihnen. Wenn Sie neue Cluster oder Buckets hinzufügen, werden diese automatisch in die Karte aufgenommen.
- Umsetzbare Anleitungen: Wir sagen Ihnen nicht nur „Sie haben eine XSS-Schwachstelle“. Wir stellen die spezifischen Behebungsschritte bereit, die Ihre Entwickler zur Behebung benötigen, wodurch die „Sicherheitsreibung“ zwischen Ihren Sicherheitszielen und Ihrer Versandgeschwindigkeit reduziert wird.
- Compliance-Bereitschaft: Für diejenigen unter Ihnen, die SOC2, HIPAA oder PCI-DSS anstreben, wird „kontinuierliches Monitoring“ zu einer Anforderung. Penetrify stellt die Audit-Protokolle und -Berichte bereit, um Ihren Auditoren nachzuweisen, dass Sie nicht nur einmal im Jahr sicher sind, sondern jeden Tag.
Fallstudie: Die „Shadow API“-Rettung
Betrachten wir ein reales Beispiel dafür, wie dies in der Praxis funktioniert. Ein SaaS-Unternehmen (wir nennen es „CloudScale“) nutzte Penetrify für die kontinuierliche Kartierung.
CloudScale hatte ein sehr diszipliniertes DevOps-Team. Sie hatten eine großartige CI/CD-Pipeline und führten Scans bei jedem Build durch. Sie waren der Meinung, dass sie absolut sicher waren.
Ein Entwickler im Produktteam wollte jedoch eine neue Integration mit einem Drittanbieter-Partner testen. Um Zeit zu sparen und die „Bürokratie“ der Haupt-Pipeline zu vermeiden, richtete der Entwickler eine kleine Instanz auf einem separaten, vergessenen AWS-Konto ein und implementierte eine „schnelle und schmutzige“ Version ihrer API.
Diese API hatte keine Authentifizierung. Es war nur ein direkter Zugang zu einer gespiegelten Version ihrer Produktionsdatenbank.
Da die API nicht Teil der „offiziellen“ Codebasis war, sahen die internen Scanner sie nie. Es war „Shadow IT“.
Aber Penetrifys kontinuierliche Angriffsflächen-Kartierung kümmert sich nicht darum, was „offiziell“ ist. Sie scannt den weiteren digitalen Fußabdruck. Innerhalb von 48 Stunden nach dem Live-Schalten der API meldete Penetrify eine neue, undokumentierte Subdomain mit einem offenen API-Endpunkt und ohne Authentifizierung.
CloudScale wurde sofort alarmiert. Sie schalteten die Instanz innerhalb einer Stunde ab. Hätten sie auf ihren jährlichen Pen Test gewartet, wäre diese API weitere sechs Monate lang offen gewesen – genug Zeit für einen Angreifer, sie zu finden.
FAQ: Häufige Fragen zur Angriffsflächen-Kartierung
F: Unterscheidet sich die kontinuierliche Kartierung von einem Schwachstellenscanner? Ja. Ein Scanner sagt Ihnen, ob eine bestimmte Tür unverschlossen ist. Die Kartierung sagt Ihnen, dass Sie zwölf Türen haben, von denen Sie nicht wussten, dass sie existieren, und drei davon sind weit offen. Bei der Kartierung geht es um Entdeckung; beim Scannen geht es um Analyse. Sie brauchen beides.
F: Verlangsamt das kontinuierliche Scannen nicht meine Anwendungen? Nicht, wenn es richtig gemacht wird. Moderne Tools wie Penetrify sind so konzipiert, dass sie nicht aufdringlich sind. Sie konzentrieren sich auf „passive“ Reconnaissance und gezieltes „aktives“ Scannen, das Ihre Server nicht übermäßig belastet. Es ist ein winziger Bruchteil des Datenverkehrs, den Ihre Website bereits verarbeitet.
F: Wir haben ein sehr kleines Team. Brauchen wir das wirklich? Tatsächlich brauchen kleine Teams dies mehr als große. Große Unternehmen haben ganze „Red Teams“, deren einziger Job darin besteht, Löcher zu finden. Wenn Sie ein kleines Team sind, haben Sie diesen Luxus nicht. Automatisierung ist der einzige Weg, um „Enterprise-Grade“-Sicherheit zu erhalten, ohne fünf Vollzeit-Sicherheitsingenieure einzustellen.
F: Ersetzt dies meinen manuellen Pen Test für die Compliance (wie SOC2)? Nicht ganz, aber es macht den manuellen Test viel einfacher. Viele Auditoren möchten immer noch eine manuelle „menschliche“ Genehmigung sehen. Wenn Sie einem Auditor jedoch ein Penetrify-Dashboard zeigen können, das beweist, dass Sie täglich scannen und beheben, wird der manuelle Test zu einer Formalität und nicht zu einem stressigen Ereignis.
F: Wie oft sollte die „Karte“ aktualisiert werden? In einer Cloud-Umgebung lautet die Antwort „kontinuierlich“. Jedes Mal, wenn Sie Code pushen, eine Firewall-Regel ändern oder einen neuen Cloud-Dienst hinzufügen, ändert sich Ihre Angriffsfläche. Das Ziel ist es, die Zeit zwischen „Schwachstelle erstellt“ und „Schwachstelle entdeckt“ so kurz wie möglich zu halten.
Abschließende Erkenntnisse: Ihr Sicherheitsaktionsplan
Die Verhinderung von Datenschutzverletzungen besteht nicht darin, die teuerste Firewall zu kaufen; es geht darum, die Anzahl der Möglichkeiten zu reduzieren, wie ein Hacker eindringen kann. Die gefährlichste Schwachstelle ist die, von der Sie nicht wissen, dass sie existiert.
Wenn Sie von einem reaktiven „Panikmodus“ zu einer proaktiven Sicherheitslage wechseln möchten, beginnen Sie hier:
- Vertrauen Sie Ihrer Asset-Liste nicht mehr. Gehen Sie davon aus, dass mindestens ein Server oder eine API gerade läuft, den Sie vergessen haben.
- Nehmen Sie eine „Outside-In“-Perspektive ein. Verwenden Sie Tools, die Ihr Netzwerk so sehen, wie es ein Angreifer tut.
- Priorisieren Sie nach Risiko, nicht nur nach Schweregrad. Beheben Sie zuerst die Dinge, die tatsächlich aus dem Internet erreichbar sind.
- Automatisieren Sie den Entdeckungsprozess. Gehen Sie weg von Point-in-Time-Audits und hin zu einem kontinuierlichen Modell.
Sicherheit ist eine Reise, kein Ziel. Ihre Angriffsfläche wächst immer mit Ihrem Unternehmen. Das Ziel ist nicht, ein „perfektes“ System zu haben – denn das gibt es nicht – sondern ein System, in dem Sie die Lücken finden, bevor es die Bösen tun.
Wenn Sie es leid sind, sich Sorgen zu machen, was sich in Ihrer Cloud-Umgebung verbirgt, ist es an der Zeit, sich ein klares Bild Ihrer Angriffsfläche zu machen. Sie können damit beginnen, zu erkunden, wie Penetrify Ihre Sicherheitstests automatisieren und Ihnen die Gewissheit geben kann, die mit kontinuierlicher Transparenz einhergeht. Besuchen Sie Penetrify.cloud, um zu sehen, wie Sie Ihre Sicherheitslage von einer Momentaufnahme in eine Live- und geschützte Umgebung verwandeln können.