NordVPN wies die jüngsten Angaben zu einem Sicherheitsvorfall zurück und erklärte, bei den mutmaßlich gestohlenen Daten habe es sich um Dummy-Informationen aus einer isolierten Testumgebung eines Drittanbieters gehandelt.
Das Unternehmen erklärte, dass weder Kundendaten noch Produktionssysteme oder aktive Zugangsdaten kompromittiert worden seien.
„Da es sich um einen vorläufigen Test handelte und nie ein Vertrag unterzeichnet wurde, wurden in diese Umgebung niemals echte Kundendaten, Produktionsquellcode oder aktive vertrauliche Zugangsdaten hochgeladen“, erklärte das Unternehmen in einer Stellungnahme gegenüber Bleeping Computer.
Was beim NordVPN-Vorfall wirklich geschah
Der Vorfall begann, als ein unter dem Pseudonym1011behauptender Akteur in einem Hackerforum angab, mehr als 10 Datenbanken von einem NordVPN-Entwicklungsserver exfiltriert zu haben.
Der Akteur behauptete, die Daten durch Brute-Force-Angriffe auf ein falsch konfiguriertes System erlangt zu haben. Sie hätten sensible Entwicklungsressourcen wie Salesforce-API-Schlüssel und Jira-Token umfasst.
Obwohl zunächst keine Kundendaten betroffen zu sein schienen, können Vorwürfe im Zusammenhang mit internen Entwicklungssystemen dennoch ein Risiko darstellen.
Selbst unbestätigte Angaben zu einem Sicherheitsvorfall können Reputationsschäden verursachen, regulatorische und Compliance-Fragen aufwerfen und Sicherheitsteams dazu zwingen, Ressourcen für die Reaktion auf den Vorfall und die Validierung abzuziehen.
Laut NordVPN ergab die interne Untersuchung, dass die Daten weder aus der Produktions- noch aus der Entwicklungsinfrastruktur des Unternehmens stammten.
Stattdessen stammten die offengelegten Informationen aus einer temporären Umgebung, die Monate zuvor während eines Tests einer automatisierten Testplattform eines Drittanbieters eingerichtet worden war.
Nach Angaben des Unternehmens wurde diese Umgebung ausschließlich zur vorläufigen Evaluierung genutzt und war nie mit den internen Systemen oder Produktionsnetzwerken von NordVPN verbunden.
Da der Test nicht zu einem unterzeichneten Vertrag führte, erklärte NordVPN, dass niemals echte Kundendaten, Produktionsquellcode oder aktive Zugangsdaten hochgeladen worden seien.
Die Datenbanken enthielten Berichten zufolge ausschließlich Dummy-Daten und Testartefakte zur Validierung der Funktionalität, nicht jedoch echte operative Informationen.
NordVPN erklärte außerdem, das Unternehmen habe den Drittanbieter kontaktiert, um zu klären, wie auf die Testumgebung zugegriffen wurde, und eine ähnliche Offenlegung künftig zu verhindern.
Das Unternehmen erklärte, es gebe keine Hinweise darauf, dass Angreifer in die Produktionssysteme von NordVPN eingedrungen oder auf aktive Zugangsdaten zugegriffen hätten.
Während der Angreifer den Vorfall als erfolgreichen Angriff auf einen NordVPN-Server darstellte, betont das Unternehmen, dass die betreffende Umgebung extern, isoliert und unabhängig von seiner Kerninfrastruktur gewesen sei.
Sicherheitslücken in Testumgebungen schließen
Vorfälle im Zusammenhang mit Test- und Entwicklungsumgebungen legen häufig Governance-Lücken offen und nicht etwa Versäumnisse bei den zentralen Sicherheitskontrollen.
Diese Systeme sind zwar typischerweise von der Produktion isoliert, können jedoch weiterhin ein Risiko darstellen, wenn Zugangsdaten, Daten oder Zugriffsrechte nicht sorgfältig verwaltet werden.
Um dieses Risiko zu reduzieren, müssen Nicht-Produktionsumgebungen als vollwertige Sicherheitsressourcen behandelt werden – mit derselben Transparenz und denselben Kontrollen wie bei Produktivsystemen.
- Testumgebungen isolieren und streng kontrollieren , um sicherzustellen, dass sie vollständig von Produktionssystemen getrennt sind und keine echten Zugangsdaten oder Kundendaten enthalten.
- Risiken durch Zugangsdaten in Entwicklungs-Workflows minimieren durch die Verwendung kurzlebiger, Tokens mit geringsten Berechtigungen und die Durchsetzung starker Authentifizierungsverfahren wie MFA und SSO.
- Ständige Transparenz über Drittanbieter-Tools und -Umgebungen gewährleisten durch die Erfassung aller QA-, Test- und Automatisierungsplattformen.
- Monitoring und Protokollierung für Nicht-Produktionssysteme einsetzen , um unbefugte Zugriffe, Brute-Force-Versuche oder anomales Verhalten frühzeitig zu erkennen.
- Synthetische oder maskierte Daten standardmäßig verwenden und das manuelle Hochladen echter Geschäfts- oder Kundendaten in Testumgebungen untersagen.
- Governance- und Stilllegungsprozesse formalisieren , damit temporäre Umgebungen nach Abschluss von Tests oder Evaluierungen zeitnah überprüft, abgesichert und außer Betrieb genommen werden.
Zusammengenommen reduzieren diese Kontrollen das Risiko, dass Testumgebungen zu unbeabsichtigten Angriffsflächen werden.
Wenn das Risiko von Anbietern zum Unternehmensrisiko wird
Der Vorfall ereignet sich zu einer Zeit, in der die Sicherheit von Anbietern, Risiken durch Drittanbieter und Software-Lieferketten verstärkt unter die Lupe genommen werden.
Bedrohungsakteure nehmen zunehmend Entwicklungspipelines, Testplattformen und externe Dienstleister als leichter angreifbare Einstiegspunkte in ansonsten gut geschützte Unternehmen ins Visier.
Daher können selbst begrenzte Vorfälle oder Offenlegungen in Nicht-Produktionsumgebungen schnell Aufmerksamkeit erregen, die Besorgnis verstärken und weitergehende Fragen zu Governance und Aufsicht aufwerfen.
Da Tools und Nicht-Produktionssysteme von Drittanbietern immer häufiger als Einstiegspunkte dienen, sind Zero-Trust-Ansätze, die jede Zugriffsanfrage überprüfen, zunehmend unverzichtbar, um Risiken in der Lieferkette zu reduzieren.