Die 3%-Regel: Wie Sie 97% Ihrer Cloud-Warnmeldungen zum Schweigen bringen und sicherer werden

Priorisieren, was zuerst behoben werden muss, und warum das so wichtig ist

Geschwindigkeit und Skalierbarkeit sind das grundlegende Versprechen der Cloud. Doch für Sicherheitsteams ist diese Skalierbarkeit zum Hauptgegner geworden. Wir bewegen uns derzeit in einem Paradoxon der Cloud-Sicherheit: Unternehmen setzen mehr Scanning-Tools ein als je zuvor, aber noch nie hatten sie so wenig Klarheit über ihre tatsächliche Risikolage.

Bisher galt in der Branche die Menge als Maßstab für Erfolg. Wie viele Probleme haben wir aufgedeckt? Wie viele haben wir gepatcht? Doch in einer modernen Cloud-Umgebung ist Menge keine Kennzahl, sondern eine Belastung. Wenn Sicherheitsteams basierend auf einem theoretischen Schweregrad mit Tausenden von „kritischen“ Warnmeldungen überflutet werden, sind sie zu einer reaktiven Haltung gezwungen. Schwachstellen-Teams sind mit diesem Szenario nur allzu vertraut. 

Die Daten zeigen eine deutliche Ineffizienz: Während herkömmliche Tools fast 60 % der Schwachstellen als „hoch“ oder „kritisch“ einstufen, zeigt Tenable Research, dass nur etwa 1,6 % bis 3 % ein tatsächliches, ausnutzbares Geschäftsrisiko darstellen. Teams sind daher gezwungen, die meiste Zeit damit zu verbringen, irrelevanten Warnmeldungen hinterherzujagen, anstatt Risiken zu minimieren.

Um den Reifegrad Ihres Programms für Cloud-Sicherheit zu erhöhen, müssen Sie aufhören, nach Schweregrad zu priorisieren, und stattdessen beginnen, nach der Ausnutzbarkeit zu priorisieren. Es ist Zeit, von Schwachstellenmanagement zu Exposure Management überzugehen.

Die operativen Kosten von theoretischem Risiko

Das CVSS-System (Common Vulnerability Scoring System) hat sich als Standard für die Priorisierung von Schwachstellen durchgesetzt. Jedoch fehlt CVSS der notwendige geschäftliche Kontext, um in allen Bereichen effektiv zu sein, insbesondere in der Cloud. CVSS misst den Schweregrad eines Softwarefehlers im luftleeren Raum, da es den Kontext des Assets nicht berücksichtigt. Ist das Asset öffentlich zugänglich? Ist es privilegiert? Greift es auf sensible Daten zu?

Wenn Ihr Team eine ausschließlich nach CVSS sortierte Liste abarbeitet, verschwendet es wertvolle Zeit mit theoretischen Schwachstellen, während echte Angriffspfade offenbleiben. Das Ziel besteht nicht darin, möglichst viel zu beheben, sondern das zu beheben, was wirklich wichtig ist. Wie heißt es so schön: „Wenn alles wichtig ist, ist nichts wichtig“.

Toxische Kombinationen: Tatsächliche Risiken definieren

In der modernen IT-Sicherheit ist im Grunde jeder Sicherheitsvorfall ein Identitätsvorfall. Zwar kann eine Fehlkonfiguration oder eine Schwachstelle der Ausgangspunkt sein, aber es sind Identitäten – und vor allem ihre Berechtigungen und Privilegien –, die einen Sicherheitsvorfall von „schlimm“ zu „schlimmer“ werden lassen.

Sicherheitsverletzungen treten selten isoliert auf. Sie treten genau an der Schnittstelle zwischen öffentlicher Zugänglichkeit, Schwachstelle und privilegierter Identität auf. Diese Konvergenz – die toxische Kombination – erzeugt das perfekte Szenario für Angreifer.

Diese Faktoren zueinander in Beziehung zu setzen, ist äußerst schwierig, da sich die Daten häufig in Silos befinden: Schwachstellendaten in einem Tool, IAM-Daten in einem anderen und die Netzwerkzugänglichkeit in einem dritten. Sicherheitsteams sind heute gefordert, diese Lücken zu schließen, indem sie Rohdaten in einen Kontext setzen, um klare Erkenntnisse zu gewinnen und entsprechende Maßnahmen zu ergreifen.

Echte Risiken entstehen durch das Zusammentreffen dieser drei Faktoren, derer sich Angreifer gerne bedienen:

• Öffentliche Zugänglichkeit: Das Asset ist über das Internet zugänglich.
• Kritische Schwachstelle: Die Software enthält eine bekannte, ausnutzbare Sicherheitslücke.
• Hohe Berechtigungen oder Zugriffsrechte: Die zugehörige Identität hat weitreichende Berechtigungen (z. B. Admin oder Root).

Bei toxischen Kombinationen ist die Schwachstelle häufig der Türöffner, doch hohe Berechtigungen geben dem Angreifer die volle Kontrolle. Doch trotz der offensichtlichen Gefahr ist laut Tenable Cloud Security Risk Report 2025 in nahezu 29 % der Unternehmen derzeit mindestens ein Workload mit genau dieser Konfiguration in Betrieb.

Diese Kombinationen sind die primären Ziele für Bedrohungsakteure, da sie einen direkten Ansatzpunkt für Datenexfiltration, Ransomware oder andere bösartige Auswirkungen bieten. Diese spezifischen Überschneidungen zu identifizieren und zu beheben, anstatt einer generischen CVE-Liste hinterherzujagen, ist der Unterschied zwischen „Fleißarbeit“ und einer tatsächlichen Risikoreduzierung durch Behebung der Gefährdung. 

Der Jenga®-Effekt: Übernommene Risiken in KI und Identitäten

Die Herausforderung der Priorisierung wird durch die rasche Einführung von KI und die vielschichtige Beschaffenheit von Cloud-Services verschärft – was Tenable Cloud Research als den „Jenga-Effekt“ bezeichnet.

Bei der Bereitstellung von KI-Workloads werden häufig riskante Standardkonfigurationen von Anbietern übernommen. Laut dem Tenable Cloud AI Risk Report 2025 haben beispielsweise 90,5 % der Unternehmen, die Amazon SageMaker konfiguriert haben, in mindestens einer Notebook-Instanz standardmäßig Root-Zugriff aktiviert. Wenn der grundlegende Block Ihres Stacks nicht sicher ist, ist der gesamte Workload gefährdet.

Hinzu kommt, dass Identitäten zum Hauptziel von Angreifern geworden sind. Sie können sämtliche Software in Ihrer Umgebung patchen, doch wenn ein Angreifer eine überprivilegierte Identität kompromittiert, braucht er keinen Exploit. Er muss sich einfach nur einloggen. Laut Tenable Cloud Research Report 2024 verfügen 84 % der Unternehmen über ungenutzte oder seit langem bestehende Zugangsschlüssel mit kritischen Berechtigungen, sodass ein effektives Identity Security Posture Management nicht mehr optional ist.

Ein ausgereiftes Exposure Management muss Identitätsrisiken und KI-Fehlkonfigurationen mit der gleichen Dringlichkeit behandeln wie Software-Schwachstellen.

Operationalisieren von Exposure Management

Um die in der Cloud bestehende Effizienzlücke zu schließen, müssen Sicherheitsverantwortliche eine Cloud Native Application Protection Platform (CNAPP) einführen, die für eine einheitliche Transparenz sorgt und eine kontextbezogene Prioritätensetzung erzwingt.

Hier erfahren Sie, wie Sie Ihr Betriebsmodell umstellen können:

1. Dynamik aufrechterhalten (das 5-Minuten-Audit)

Lähmung ist der Feind der Sicherheit. Angesichts eines Berges von Warnmeldungen erstarren Teams häufig. Tenable Cloud Security überwindet diese Lähmung mit dem Widget „If you only have 5 minutes“. Bei dieser Funktion geht es nicht um tiefgreifende forensische Analysen, sondern um Hygiene und Dynamik. Sie identifiziert die unmittelbaren, offensichtlichen „Quick Wins“, wie z.B. einen öffentlich zugänglichen S3-Bucket oder einen inaktiven Schlüssel, der sofort behoben werden kann. So wird gewährleistet, dass Sie selbst an Ihren arbeitsreichsten Tagen etwas beheben, anstatt gar nichts. Es verhindert, dass sich alltägliche Probleme auftürmen, während Sie sich auf intensivere Arbeit vorbereiten. Das ist ein idealer Ansatzpunkt für Sicherheitsteams, um Mitarbeitende auf Junior-Level einzubinden.

2. Toxische Kombinationen angehen

Sobald die Quick Wins erledigt sind, sollten Sie sich strategischen Risiken konzentrieren. Dies ist der Punkt, an dem Sie die toxischen Kombinationen ins Visier nehmen. An dieser Stelle sollten Sie Ihre besten Mitarbeiter einsetzen. Indem Sie Identitäts-, Netzwerk- und Schwachstellendaten miteinander in Beziehung setzen, können Sie die 3 % der Warnmeldungen identifizieren, die zu einem verheerenden Angriff führen könnten. Die Behebung dieser Sicherheitslücken führt zu einer messbaren Reduzierung des Unternehmensrisikos, die Sie dem Vorstand melden können.

3. Behebungsmaßnahmen an die Quelle verlagern

„ClickOps“, das manuelle Festlegen von Einstellungen in der Cloud-Konsole, ist ineffizient und vorübergehend. Bei der nächsten Bereitstellung wird die Korrektur häufig überschrieben.

Unternehmen mit hohem Reifegrad integrieren Sicherheit in den gesamten Entwicklungszyklus. Tenable Cloud Security verfolgt Runtime-Probleme bis zu der spezifischen Infrastructure as Code (IaC) zurück, die sie verursacht hat. Anschließend kann die Lösung automatisch eine Pull-Anfrage mit den erforderlichen Codeänderungen erstellen.

Das Gleiche gilt für Identitäten. Anstatt Berechtigungen abzuschätzen, analysiert die Plattform das tatsächliche Nutzungsverhalten, um Least Privilege-Richtlinien zu erstellen, die ungenutzte Zugriffsrechte automatisch entfernen.

Fazit: Wertorientierte Sicherheit

Die Kennzahl für ein erfolgreiches Cloud-Sicherheitsprogramm ist nicht länger die „Anzahl der erledigten Warnmeldungen“, sondern die messbare Verringerung der Exposure.

Wir können zwar nicht unsere Teams skalieren, um mit dem Wachstum der Cloud Schritt zu halten, aber wir können unser Wissen skalieren. Indem Sie Kontext nutzen, um die 3 % der Sicherheitslücken zu identifizieren, die ein Geschäftsrisiko darstellen, kann Ihr Unternehmen von einer reaktiven Haltung zu einer proaktiven Priorisierung und Behebung von Sicherheitslücken übergehen.

Erleben Sie die Lösung in Aktion

Die folgende kurze Demo führt Sie durch eine reale Cloud-KI-Umgebung und zeigt, wie Tenable Workloads identifiziert, verborgene Risiken aufdeckt und die wichtigsten Probleme hervorhebt.

Sie erhalten einen schnellen, unkomplizierten Einblick in Exposure Management, der Ihnen ein Gefühl für die Anwendung in der Praxis vermittelt.

Erfahren Sie mehr über die Priorisierung von Cloud-Risiken auf der Grundlage dessen, was wirklich wichtig ist.

(Jenga® ist eine eingetragene Marke im Besitz von Pokonobe Associates.)