CVSS ist ein Baustein der Bewertung, aber nicht automatisch das Risiko. Ein CVSS-Wert beschreibt die technische Schwere einer Schwachstelle; das Risiko entsteht erst im konkreten Kontext - aus Ausnutzbarkeit, Voraussetzungen, Exposition, tatsächlich wirksamen Kontrollen, Angriffspfaden und Business Impact. Dieser Artikel zeigt, wie ein Pentester diese Dimensionen sauber auseinanderhält und zu einer nachvollziehbaren, begründeten Einstufung kommt: ohne erfundene Formel, ohne Scheingenauigkeit, ohne künstliche Hochstufung. Er ist die methodische Ergänzung zum Deep-Dive Pentest Reporting und greift dessen Trennung von Finding-Severity und Pfadrisiko sowie die vier Nachweisstufen auf.
Severity ist nicht Risk
Die häufigste Verwechslung in Pentest-Berichten ist die zwischen Severity und Risiko. Severity beschreibt, wie schwer eine Schwachstelle technisch wiegt - was sie im Prinzip erlaubt, unabhängig davon, wo sie steckt. Risiko beschreibt, was sie in dieser Umgebung für dieses Unternehmen bedeutet. Beides hängt zusammen, aber keines folgt automatisch aus dem anderen. Ein technisch schwerer Befund kann organisatorisch ein niedriges Risiko sein, und ein technisch moderater Befund kann durch Exposition oder Verkettung ein hohes Risiko erzeugen.
| Severity | Risk | |
|---|---|---|
| Frage | Wie schwer wiegt die Schwachstelle technisch? | Was bedeutet sie hier, für dieses Unternehmen, in diesem Umfeld? |
| Bezugspunkt | Die Schwachstelle selbst: Angriffsvektor, Komplexität, Rechte, Auswirkung auf das betroffene System | Die Schwachstelle im Kontext: Exposition, Voraussetzungen, wirksame Kontrollen, Angriffspfad, Business Impact |
| Ändert sich, wenn | sich die Schwachstelle ändert - etwa durch eine andere Version oder Konfiguration | sich das Umfeld ändert - Netzsegment, Datenklasse, Rolle des Systems, Kontrollen, Nachbarbefunde |
| Standardisierbar | Weitgehend - CVSS liefert dafür eine gemeinsame Sprache | Nur im Vorgehen, nicht im Ergebnis - das Ergebnis ist kundenspezifisch |
| Wo im Bericht | Im Finding als technische Severity, gegebenenfalls mit CVSS-Vektor | Im Finding als finale Risikoeinstufung (Risk Rating) mit Begründung; auf Pfadebene als Pfadrisiko |
Zwei kontrastierende Beispiele machen den Unterschied greifbar. Erstens: Eine Remote-Code-Execution in einer veralteten Komponente - technisch hoch bis kritisch. Das betroffene System ist aber ein isolierter Build-Server in einem eigenen Segment, ohne produktive Daten, nur aus dem Admin-Netz erreichbar, und das Allowlisting hat im Test die nachgelagerte Ausführung des vorgesehenen Payloads verhindert - der verwundbare Codepfad war belastbar bestätigt, die Ausnutzung blieb im Szenario vor der Codeausführung stehen. Das organisatorische Risiko ist deutlich niedriger als die technische Schwere. Zweitens: Eine anonym lesbare Dateifreigabe - technisch mittel. Sie ist aber aus dem gesamten Client-Netz erreichbar, braucht keine Zugangsdaten, enthält ein Dienstkonto und ist der erste Schritt eines Pfads bis zur Kundendatenbank. Das tatsächliche Risiko ist hoch. Beide Bewertungen sind korrekt - weil sie auf verschiedene Dinge zeigen. Die Begriffe Finding, Vulnerability, Exploitability und Risk, die der Grundlagenartikel einführt, bilden genau diese Trennung ab.
Ein Bewertungsmodell für Pentests
Ein brauchbares Modell ist keine Formel, in die man Zahlen einsetzt, sondern eine feste Menge von Dimensionen, die bei jedem Finding betrachtet werden, mit einer klaren Richtung: Welche Dimension hebt die Bewertung, welche senkt sie, und wie wird das Ergebnis begründet. Der Wert liegt in der Konsistenz des Vorgehens, nicht in der Präzision einer Zahl.
| Dimension | Leitfrage | Hebt die Bewertung | Senkt die Bewertung |
|---|---|---|---|
| Technische Schwere | Was erlaubt die Schwachstelle im Prinzip? | Codeausführung, vollständiger Datenzugriff, Rechteübernahme | Informationsabfluss ohne direkten Hebel, eingeschränkte Wirkung |
| Exploitability | Wie zuverlässig und mit welchem Aufwand ist sie hier ausnutzbar? | Stabil reproduzierbar, geringer Aufwand, keine Sonderbedingungen | Race Conditions, Timing, hoher Aufwand, nur unter Sonderbedingungen |
| Erforderliche Privilegien / Voraussetzungen | Was muss ein Angreifer vorher besitzen? | Nichts - unauthentifiziert, ohne Vorwissen | Admin-Rechte, gültige Zugangsdaten, Spezialwissen, physische Präsenz |
| User Interaction | Muss ein Nutzer mitwirken? | Keine Interaktion nötig | Ein Nutzer muss klicken, öffnen, bestätigen - idealerweise ein privilegierter |
| Exposure / Reachability | Wer kann das verwundbare System überhaupt erreichen? | Internet, gesamtes internes Netz, alle Mitarbeiter | Ein Segment, ein Management-Netz, eine kleine Rollengruppe |
| Vorhandene Schutzmaßnahmen | Welche Kontrolle wirkt im konkreten Szenario nachweislich? | Keine wirksame Kontrolle; Kontrolle vorhanden, aber im Test umgangen | Kontrolle hat den Schritt im Test tatsächlich verhindert oder begrenzt |
| Business Impact | Was bedeutet die Ausnutzung für Daten, Betrieb, Prozesse, Pflichten? | Kritische Datenklassen, Kernprozesse, regulatorische Folgen | Unkritische Daten, Testsysteme, leicht ersetzbare Funktionen |
| Angriffspfad / Verkettung | Wohin führt der Befund in Verbindung mit anderen? | Glied eines Pfads zu einem kritischen Ziel - bewertet auf Pfadebene | Isoliert, kein weiterführender Schritt erkennbar |
| Unsicherheit / Belegstufe | Bis zu welcher Stufe ist der Befund belegt? | Impact verifiziert - die Bewertung trägt | Nur identifiziert - die Bewertung wird mit ausgewiesener Unsicherheit versehen, nicht abgesenkt |
Das Ergebnis wird nicht errechnet, sondern begründet: Die technische Schwere ist der Ausgangspunkt, Exploitability, Voraussetzungen, User Interaction, Exposure und wirksame Kontrollen verschieben die Wahrscheinlichkeit, Business Impact und Pfadbezug verschieben die Wirkung. Die Begründung nennt die Dimensionen, die den Ausschlag gegeben haben - in einem Satz, der ohne den Tester nachvollziehbar ist. Wie diese Begründung in ein Finding gehört, zeigt der Abschnitt zum Beispiel-Finding.
CVSS korrekt einordnen
Das Common Vulnerability Scoring System hat einen klaren Zweck: die technische Schwere einer Schwachstelle in einer standardisierten, vergleichbaren Form auszudrücken. Es liefert einen Wert von 0 bis 10 und einen Vektor, der die Einzelbewertungen offenlegt. Genau darin liegt sein Nutzen - und seine Grenze. CVSS misst Severity. Es misst nicht automatisch das Risiko für eine Organisation, und es war nie dafür gedacht, diese Entscheidung abzunehmen.
CVSS v4 ordnet die Bewertung in vier Metrikgruppen - Base, Threat, Environmental und Supplemental Metrics -, die methodisch verschiedene Fragen beantworten. Entscheidend ist nicht, jede Metrik zu kennen, sondern zu verstehen, wann welche Gruppe relevant wird:
| Ebene | Was sie beschreibt | Wann sie im Pentest relevant wird |
|---|---|---|
| Base Metrics | Die Schwachstelle selbst: Angriffsvektor, Komplexität, Angriffsvoraussetzungen, erforderliche Rechte, Nutzerinteraktion sowie die Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit - getrennt nach dem verwundbaren System und nachgelagerten Systemen | Immer, als technische Referenz. Sie ist umgebungsunabhängig und damit das, was ein Hersteller oder eine Datenbank liefert |
| Threat Metrics | Über Exploit Maturity, wie weit die praktische Ausnutzung einer Schwachstelle entwickelt beziehungsweise beobachtet ist - Zustände: Unreported, Proof-of-Concept, Attacked | Wenn bekannte Software-Schwachstellen bewertet werden; ein Proof-of-Concept oder beobachtete aktive Ausnutzung können den Threat-Anteil verändern |
| Environmental Metrics | Die konkrete Einsatzumgebung: Modified Base Metrics, die die Base-Werte an das reale Szenario anpassen, sowie die Security Requirements für Vertraulichkeit, Integrität und Verfügbarkeit des betroffenen Systems | Relevant, wenn CVSS für den konkreten Befund verwendet wird und belastbare Informationen zur tatsächlichen Einsatzumgebung vorliegen. Segmentierung oder tatsächliche Erreichbarkeit lassen sich berücksichtigen, soweit sie sich korrekt über die Modified Metrics des Szenarios abbilden lassen. Business Impact, Angriffspfade, regulatorische Folgen und die Risikotoleranz des Unternehmens sind keine Environmental Metrics |
| Supplemental Metrics | Ergänzende Einordnungen - Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort und Provider Urgency - ohne Einfluss auf den CVSS-Zahlenwert | Als zusätzliche Information, wo sie dem Leser hilft; sie ersetzen keine Risikoaussage |
Die Spezifikation benennt die resultierenden Werte nach den einbezogenen Gruppen: CVSS-B (nur Base), CVSS-BT (Base und Threat), CVSS-BE (Base und Environmental) und CVSS-BTE (alle drei). Daraus ergibt sich, warum der Base Score allein im Pentest oft nicht genügt: Er beschreibt die intrinsischen Eigenschaften der Schwachstelle unabhängig von zeitlichen Threat-Faktoren und von einer konkreten Nutzerumgebung - nicht, wie sie hier wirkt. Erst die Environmental Metrics bringen Einsatzumgebung und Schutzbedarf ein, und selbst ein vollständig kontextualisierter CVSS-BTE-Wert bleibt eine Severity-Aussage über eine einzelne Schwachstelle. Angriffspfade, organisatorische Folgen und die Frage, was ein Angreifer mit dieser Schwachstelle in dieser Umgebung tatsächlich erreicht, liegen außerhalb dessen, was das Scoring abbilden soll. Für die vollständige Metrik-Definition ist die Spezifikation des FIRST die richtige Quelle; dieser Artikel bleibt bewusst bei der methodischen Einordnung.
CVSS im Pentest praktisch verwenden
CVSS ist im Bericht dann wertvoll, wenn es das tut, wofür es gemacht ist: technische Vergleichbarkeit herstellen. Und es wird zum Problem, wenn es Aufgaben übernehmen soll, für die es nicht gebaut wurde.
| CVSS ist sinnvoll bei | CVSS allein reicht nicht bei |
|---|---|
| Standardisierter technischer Vergleichbarkeit - zwei Schwachstellen derselben Art lassen sich über Berichte und Teams hinweg einordnen | Internen Fehlkonfigurationen - ein anonym lesbares Share oder ein Gastzugriff hat keinen CVE und keinen Herstellerscore; der Vektor lässt sich bilden, trägt aber wenig Information |
| Schwachstellenklassen - eine Klasse wie fehlende Zugriffsprüfung oder Injection bekommt eine konsistente technische Ausgangsbewertung | Berechtigungspfaden und AD-Angriffspfaden - eine ACL-Kante oder eine Delegationskonfiguration ist allein harmlos und erst in der Kette relevant; vertieft im AD-Deep-Dive |
| Externen Referenzen - bekannte Software-Schwachstellen bringen einen Herstellerscore mit, auf den sich der Bericht beziehen kann | Business-Logic-Fehlern - ein Rabattcode, der sich mehrfach einlösen lässt, lässt sich je nach Implementierung zwar als Integritätsauswirkung abbilden, aber CVSS erfasst den geschäftlichen Schaden eines Business-Logic-Fehlers häufig nur unvollständig; vertieft im Web-Deep-Dive |
| Konsistenter technischer Bewertung - der Vektor macht sichtbar, warum zwei Befunde verschieden bewertet wurden | Segmentierungsfehlern und Credential-Reuse - eine offene Firewall-Regel oder ein auf mehreren Hosts gültiges Dienstkonto ist keine Schwachstelle eines Systems, sondern eine Eigenschaft des Netzes; vertieft im Netzwerk-Deep-Dive |
| Organisatorischen Auswirkungen und kombinierten Findings - was ein Pfad für das Unternehmen bedeutet, steht in keinem Vektor |
Die praktische Regel: CVSS gehört als technische Referenz ins Finding, wo es eine trägt - mit Vektor, nicht nur mit Zahl, damit die Einzelbewertung nachvollziehbar ist. Die finale Einstufung und die Risikoaussage werden daneben getroffen und begründet, nicht daraus abgeleitet.
Base Score gegen konkreten Kontext
Die beiden Beispiele aus dem ersten Abschnitt lassen sich entlang der Dimensionen durchdeklinieren. Die Tabelle zeigt, wie dieselbe Methodik zu gegensätzlichen Ergebnissen führt - nicht, weil die Maßstäbe wechseln, sondern weil die Dimensionen verschieden ausgeprägt sind.
| Dimension | Beispiel A: RCE auf Build-Server | Beispiel B: Offenes Share mit Dienstkonto |
|---|---|---|
| Technische Schwere | Hoch bis kritisch - Codeausführung | Mittel - Lesezugriff auf interne Dateien |
| Exploitability | Öffentlicher, stabiler Exploit vorhanden; verwundbarer Codepfad belastbar bestätigt | Trivial - Freigabe öffnen |
| Voraussetzungen | Zugang zum Management-Netz, in dem nur Administratoren arbeiten | Netzzugang im Client-VLAN, kein Konto |
| User Interaction | Keine | Keine |
| Exposure | Ein Segment, wenige Personen | Alle Arbeitsplätze |
| Wirksame Kontrollen | Allowlisting hat die nachgelagerte Ausführung des vorgesehenen Payloads im Szenario verhindert; keine produktiven Daten | Keine - Zugriff weder verhindert noch erkannt |
| Business Impact | Gering - isoliertes System, Wiederaufbau aus Pipeline möglich | Hoch - Dienstkonto mit Rechten auf dem Datenbankserver |
| Pfadbezug | Kein weiterführender Pfad erkennbar | Schritt 1 von AP-1 zur Kundendatenbank |
| Belegstufe | Technische Betroffenheit bestätigt (Stufe 1); Codeausführung im Szenario durch die Kontrolle nicht erreicht - Impact nicht vollständig verifiziert, durch die Kontrolle begrenzt | Impact verifiziert (Stufe 3) |
| Technische Severity | Hoch | Mittel |
| Finale Risikoeinstufung | Mittel - Begründung: Exposition auf Admin-Netz begrenzt, Kontrolle nachweislich wirksam, kein produktiver Impact | Hoch - Begründung: breite Exposition ohne Voraussetzungen, Dienstkonto mit Reichweite, Einstieg in einen kritischen Pfad |
Beide Einstufungen enthalten die technische Severity unverändert und daneben die finale Risikoeinstufung mit Begründung. Das ist der Kern: Die technische Schwere wird nicht überschrieben, sondern eingeordnet. Wer nur die finale Stufe sieht, kann über den Vektor und die Begründung nachvollziehen, wie sie entstanden ist.
Attack-Path-Risk
Der Reporting-Deep-Dive trennt zwei Bewertungsebenen: die Finding-Severity, die den einzelnen Befund nach der dokumentierten Methodik bewertet, und das Pfadrisiko, das beschreibt, was eine Verkettung für das Unternehmen bedeutet - ein Path- beziehungsweise Business-Risk. Dieser Abschnitt zeigt, wie die zweite Ebene methodisch entsteht und warum sie die erste nicht verändert.
Drei Fragen entscheiden, wie der Pfad bewertet wird und was das für die Glieder bedeutet:
- Warum wird kein Finding künstlich hochgestuft? Weil die Finding-Severity eine Aussage über den einzelnen Befund ist und bleibt. Das Finding behält innerhalb der dokumentierten Bewertungsmethodik seine eigene Bewertung; der zusätzliche Pfadbezug wird separat als Pfadrisiko bewertet. Würde das Share allein wegen des Pfads auf "Kritisch" gesetzt, wäre nicht mehr erkennbar, welcher Teil der Bewertung aus dem Befund selbst und welcher aus der Verkettung stammt. Der Pfadbezug steht im Finding - als Verweis, nicht als Hochstufung.
- Warum ist der Pfad trotzdem kritisch? Weil das Pfadrisiko eine andere Frage beantwortet: Was erreicht ein Angreifer, der alle Glieder nacheinander nutzt? Hier: von jedem Arbeitsplatz aus ohne Voraussetzungen bis zur Kundendatenbank. Diese Aussage ist eine Business-Risk-Aussage über das Zusammenspiel, und sie ist unabhängig davon kritisch, dass jedes einzelne Glied für sich moderat ist.
- Wie wird die Wirkung einer einzelnen Behebung bewertet? Je Glied wird gefragt, ob seine Behebung den Pfad unterbricht, nur erschwert oder den Impact am Ende begrenzt. Die Segmentgrenze zu schließen unterbricht AP-1 und mehrere weitere Pfade. Das Dienstkonto zu rotieren unterbricht AP-1 und entwertet das Share erheblich. Die lokalen Adminrechte zu entziehen begrenzt nur den Impact am Ende. Diese Spalte ist die Grundlage für die Priorisierung - nach Wirkung auf den Pfad, nicht nach dem Severity-Etikett des Glieds.
Business Impact
Technische Wirkung wird zu Business Impact, wenn sie auf das abgebildet wird, was das Unternehmen tatsächlich verliert oder nicht mehr kann. "Lesezugriff auf eine Datenbank" ist technische Wirkung. "Einsicht in die Vertragsdaten aller Kunden, meldepflichtig, mit Reputationsfolge" ist Business Impact. Der Übergang gelingt, wenn der Tester die technische Wirkung entlang weniger fester Dimensionen befragt - und ehrlich sagt, was er davon belegen kann und was er vom Auftraggeber wissen muss.
| Dimension | Leitfrage | Woher die Antwort kommt |
|---|---|---|
| Vertraulichkeit | Welche Daten könnten eingesehen werden, und wie sensibel sind sie? | Tester belegt den Zugriff; Datenklasse kommt vom Auftraggeber |
| Integrität | Was könnte verändert werden - Daten, Konfigurationen, Transaktionen? | Tester belegt die Schreibmöglichkeit; Tragweite kommt aus dem Prozess |
| Verfügbarkeit | Was könnte ausfallen, und wie lange? | Tester belegt den Hebel; Toleranz des Ausfalls kommt vom Betrieb |
| Betriebsunterbrechung | Welche Abläufe stehen still, wenn das System oder die Daten fehlen? | Auftraggeber - Abhängigkeiten sind im Test selten sichtbar |
| Kritische Geschäftsprozesse | Hängt ein Kernprozess - Abrechnung, Produktion, Kundenservice - an diesem System? | Auftraggeber; der Tester kann es aus der Rolle des Systems vermuten, nicht belegen |
| Regulatorische Auswirkungen | Lösen Datenklasse oder Vorfall Melde- oder Nachweispflichten aus? | Datenschutz- und Compliance-Seite des Auftraggebers |
| Datenklassen | Personenbezogen, Finanzdaten, Geschäftsgeheimnisse, Zugangsdaten? | Tester erkennt die Klasse am Beispiel; Einstufung nach Schutzbedarf vom Auftraggeber |
| Finanzielle Auswirkungen | Welche Kosten entstehen direkt oder indirekt? | Nur mit Datenbasis des Auftraggebers - sonst qualitativ beschreiben |
| Wiederherstellungsaufwand | Wie aufwendig ist Bereinigung, Wiederaufbau, Rotation betroffener Konten? | Tester kann den Umfang der betroffenen Objekte liefern; Aufwand schätzt der Betrieb |
Ein Grundsatz gilt dabei ohne Ausnahme: keine künstlichen Euro-Beträge ohne Datenbasis. Ein Pentester kennt in der Regel weder Umsatzabhängigkeiten noch Vertragsstrafen noch Wiederherstellungskosten. Ein erfundener Betrag wirkt präzise und ist es nicht - und er wird im Management zitiert, lange nachdem jeder weiß, dass er geschätzt war. Business Impact wird qualitativ beschrieben, an die belegte technische Wirkung gebunden und dort, wo Zahlen hingehören, dem Auftraggeber zur Ergänzung überlassen.
Voraussetzungen und Exposure
Dieselbe Schwachstelle verändert ihr Risiko erheblich, je nachdem, wer sie erreichen kann und was ein Angreifer dafür mitbringen muss. Die Matrix macht die typischen Ausprägungen explizit - sie ist kein Rechenwerk, sondern eine Checkliste, mit der die Wahrscheinlichkeitsseite der Bewertung begründet wird.
| Faktor | Risiko tendenziell höher | Risiko tendenziell niedriger | Worauf zu achten ist |
|---|---|---|---|
| Erreichbarkeit | Aus dem Internet erreichbar | Nur aus dem internen Netz oder einem Segment | "Intern" ist keine Entwarnung - Assumed Breach und Phishing machen das interne Netz zum realistischen Startpunkt |
| Authentisierung | Unauthentifiziert ausnutzbar | Gültiges Konto erforderlich | Wie leicht ist ein Konto zu bekommen? Standardkonten sind im internen Test oft Ausgangslage |
| Rolle | Standard-Nutzer genügt | Administrative Rechte nötig | Ein Admin-Befund ist oft Privilege-Escalation-Hebel, nicht Einstieg - im Pfad trotzdem relevant |
| Lokale Präsenz | Remote ausnutzbar | Physischer Zugang oder lokale Sitzung nötig | Für Innentäter- und Vor-Ort-Szenarien gilt die Hürde nicht |
| Segment | Aus dem Client- oder Nutzernetz erreichbar | Nur aus einem Management- oder Admin-Segment | Die Segmentgrenze muss im Test tatsächlich gehalten haben, sonst zählt sie nicht |
| Bekannte Zugangsdaten | Keine nötig, oder Default-Zugang aktiv | Spezifische, nicht erratbare Zugangsdaten nötig | Credential-Reuse und Zugangsdaten in Skripten heben die Hürde faktisch auf |
| User Interaction | Keine Interaktion nötig | Ein Nutzer muss klicken, öffnen oder bestätigen | Wie realistisch ist die Interaktion? Ein Link in einer internen Mail ist eine niedrige Hürde |
Die rechte Spalte ist die wichtigste: Jede senkende Ausprägung gilt nur, wenn sie im konkreten Umfeld tatsächlich besteht. "Nur authentifiziert" senkt das Risiko nicht, wenn der Test mit einem bereitgestellten Standardkonto begann und jeder Mitarbeiter eines hat. Die Matrix wird also nicht abgehakt, sondern gegen die Ausgangslage des Tests gelesen, wie sie in Scope und Rules of Engagement festgelegt wurde.
Bestehende Kontrollen
Vorhandene Schutzmaßnahmen sind der Teil der Bewertung, bei dem am häufigsten zu großzügig gerechnet wird. Die Regel ist einfach und unbequem: Eine Kontrolle darf das Risiko nur senken, wenn sie im konkreten Szenario tatsächlich wirksam war. Nicht "EDR vorhanden, also Risiko niedriger", sondern "EDR hat den konkreten Schritt verhindert, erkannt oder begrenzt - belegt durch E-12-03". Eine Kontrolle, die existiert, aber im Test nichts bewirkt hat, ist für diese Bewertung nicht vorhanden.
| Kontrolle | Senkt das Risiko, wenn belegt ist, dass | Senkt es nicht, wenn |
|---|---|---|
| MFA | der zweite Faktor am relevanten Zugang tatsächlich verlangt wurde und sich im Test nicht umgehen ließ | er nur an anderen Zugängen aktiv ist, Legacy-Protokolle ihn umgehen oder Sessions ohne ihn weiterlaufen |
| Segmentierung | die Verbindung in der Segmentierungs-Matrix als blockiert erwartet und im Test als blockiert bestätigt wurde | sie nur im Netzplan existiert; "sollte getrennt sein" ist keine Kontrolle |
| EDR | der konkrete Schritt blockiert wurde - oder bei reiner Erkennung die gesamte Reaktionskette vom Alarm bis zur wirksamen Reaktion im relevanten Zeitfenster belegt ist | der Agent installiert ist, der Schritt aber unbemerkt lief |
| Application Allowlisting | die Ausführung fremden Codes im Test tatsächlich scheiterte | Ausnahmen oder erlaubte Interpreter den Schutz umgehen |
| Netzwerkfilter | der benötigte Port oder Dienst vom relevanten Ausgangspunkt aus nicht erreichbar war | die Regel nur aus einer anderen Richtung greift als der getesteten |
| Rollen- / Berechtigungsmodell | die Rolle des Angreifers die kritische Aktion nachweislich nicht ausführen konnte | die Rolle zu breit vergeben ist oder Standardkonten effektiv dieselben Rechte haben |
| Logging / Detection | Testaktionen erkannt, gemeldet und innerhalb des relevanten Zeitfensters wirksam beantwortet wurden, mit Zeitbezug zur Aktion - ein Alarm allein senkt das Risiko nicht | Logs geschrieben, aber nicht ausgewertet werden - Protokollierung ist keine Erkennung |
| Rate Limits | die Technik im Test durch das Limit praktisch unbrauchbar wurde | das Limit pro IP gilt und sich trivial verteilen lässt |
| Zusätzliche Freigabeprozesse | eine kritische Aktion eine zweite Person erforderte und das im Test nicht umgehbar war | der Prozess existiert, aber technisch nicht erzwungen wird |
Jede berücksichtigte Kontrolle steht mit ihrem Beleg im Finding. Das ist nicht nur methodische Sauberkeit: Es macht dem Auftraggeber sichtbar, welche seiner Maßnahmen wirken - der Stoff für die positiven Beobachtungen im Bericht - und welche nur auf dem Papier existieren.
Detection ist nicht automatisch Prevention
Ein Spezialfall der Kontrollen verdient einen eigenen Abschnitt, weil er so oft falsch gerechnet wird: Ein Alarm senkt nicht die technische Ausnutzbarkeit. Wenn ein Angriff erkannt, aber nicht verhindert wird, ist die Schwachstelle genauso ausnutzbar wie ohne Erkennung - der Angreifer hat nur weniger Zeit. Deshalb unterscheidet die Bewertung drei Arten von Kontrollen nach dem, was sie tatsächlich tun:
| Kontrolltyp | Was sie bewirkt | Wirkung auf die Bewertung | Beispiel |
|---|---|---|---|
| Preventive Control | Verhindert den Schritt | Senkt die Ausnutzbarkeit oder Exposition - sofern im Test belegt | Segmentgrenze, die hält; Allowlisting, das blockiert; MFA, die nicht umgehbar war |
| Detective Control | Erkennt den Schritt und löst eine Reaktion aus | Senkt nicht die Ausnutzbarkeit; kann das Gesamtrisiko senken, wenn die gesamte Reaktionskette - Erkennung, Alarmierung, wirksame Reaktion im relevanten Zeitfenster - belegt ist, nicht schon bei der Erzeugung eines Alerts | EDR-Alarm mit nachgewiesener Reaktion; Monitoring, das den Querverkehr gemeldet hat |
| Compensating Control | Gleicht eine fehlende primäre Maßnahme teilweise aus | Senkt das Risiko nur im Umfang der belegten Wirkung - nie auf das Niveau der eigentlichen Maßnahme | Strenger Netzwerkfilter vor einem nicht patchbaren System; manuelle Freigabe statt technischer Sperre |
Detection kann das Gesamtrisiko sehr wohl beeinflussen - aber nur über die Zeitachse und nur, wenn zwei Dinge belegt sind: dass die Erkennung im Test tatsächlich ausgelöst hat, und dass jemand darauf reagieren kann, bevor der Impact eintritt. Ein Alarm, der am Wochenende in einer Konsole aufläuft, ändert an der Bewertung eines Pfads, der in einer Stunde zur Kundendatenbank führt, nichts. Diese Unterscheidung gehört ausformuliert ins Finding: welche Kontrolle, welcher Typ, welche belegte Wirkung.
Ob eine Detective Control im Test tatsächlich ausgelöst hat, lässt sich nur mit Zeitstempeln, Quell-IP und Testkonto aus dem Bericht gegen die Alarme der Gegenseite abgleichen. Welche Signale Scans, Credential-Zugriffe, Ost-West-Verkehr und Rechteausweitung auf der Verteidigungsseite erzeugen, behandelt das Schwesterportal blue-team.net.
Unsicherheit und Belegstufe
Die vier Nachweisstufen aus dem Reporting-Deep-Dive - identifiziert, Ausnutzbarkeit belegt, Impact verifiziert, vollständige Ausnutzung - sind auch für die Bewertung zentral. Je geringer die Belegstufe, desto transparenter muss die Unsicherheit ausgewiesen werden. Das bedeutet nicht, dass ein nur identifizierter Befund automatisch niedriger eingestuft wird; es bedeutet, dass die Einstufung die Unsicherheit benennt, statt sie zu verstecken.
| Belegstufe | Was die Bewertung tragen kann | Wie die Unsicherheit ausgewiesen wird |
|---|---|---|
| 1 - Identifiziert | Die technische Severity, eine begründete Annahme zu Exploitability und Impact | "Einstufung basiert auf Konfigurations- und Versionsbefund; Ausnutzbarkeit im Umfeld nicht verifiziert" - mit Grund, warum nicht (Stabilität, RoE, Zeit) |
| 2 - Ausnutzbarkeit belegt | Severity und Wahrscheinlichkeitsseite; der Impact bleibt abgeleitet | "Ausnutzbarkeit belegt (E-xx); Impact aus Rolle und Rechten des Systems abgeleitet, nicht aktiv verifiziert" |
| 3 - Impact verifiziert | Die vollständige Bewertung inklusive Business Impact am Beispiel | Keine Unsicherheit auf technischer Seite; offene Punkte nur noch beim Business-Kontext, der vom Auftraggeber kommt |
| 4 - Vollständige Ausnutzung | Nichts, was Stufe 3 nicht auch trägt | Entfällt - und ist für die Bewertung in der Regel nicht nötig |
Scheingenauigkeit ist der Gegner dieses Abschnitts. Ein Finding, das nur identifiziert wurde, bekommt keine Bewertung mit zwei Dezimalstellen und keinen Satz, der sich wie ein verifizierter Impact liest. Es bekommt eine ehrliche Stufe mit einem ehrlichen Vorbehalt - und dieser Vorbehalt ist für den Auftraggeber eine Information, keine Schwäche: Er sagt, wo ein Retest oder eine eigene Nachprüfung die Unsicherheit beseitigen kann.
Risikomatrix und Entscheidungslogik
Die klassische Matrix aus Wahrscheinlichkeit und Impact ist im Pentest nur dann brauchbar, wenn klar ist, woraus die Wahrscheinlichkeit entsteht. Sie ist keine Schätzung aus dem Bauch, sondern das Ergebnis der bereits betrachteten Dimensionen auf der Wahrscheinlichkeitsseite. Erst danach kommt der Impact als eigene Achse dazu.
Zur Einordnung: Das folgende Modell ist ein nachvollziehbares Pentest-Risikomodell für diesen Artikel - keine CVSS-Matrix und keine universell normative Vorgabe. Organisationen können andere dokumentierte Modelle verwenden; entscheidend ist, dass das verwendete Modell im Bericht benannt und konsequent angewandt wird.
| Likelihood-Faktor | Spricht für hohe Likelihood | Spricht für niedrige Likelihood |
|---|---|---|
| Exposure | Breit erreichbar - Internet oder gesamtes internes Netz | Ein Segment, eine kleine Rollengruppe |
| Voraussetzungen | Keine oder im Umfeld ohnehin gegeben | Hoch und im Umfeld real schwer zu erfüllen |
| Exploitability | Stabil, geringer Aufwand, bekannt | Unzuverlässig, aufwendig, Sonderbedingungen |
| Erforderliche Privilegien | Keine oder Standard-Nutzer | Administrative Rechte |
| User Interaction | Keine | Erforderlich und unwahrscheinlich |
| Vorhandene Kontrollen | Keine wirksame; vorhandene im Test umgangen | Preventive Control im Test belegt wirksam |
Die Likelihood wird aus diesen Faktoren als Stufe begründet - niedrig, mittel oder hoch - nicht errechnet. Der Impact wird aus technischer Wirkung und Business-Kontext separat als Stufe begründet. Die Kombination ergibt die finale Risikostufe:
| Likelihood \ Impact | Gering | Mittel | Hoch | Kritisch |
|---|---|---|---|---|
| Niedrig | Informational / Low | Low | Medium | Medium / High |
| Mittel | Low | Medium | High | High |
| Hoch | Low / Medium | High | High / Critical | Critical |
Die Felder mit zwei Werten sind Absicht: Dort entscheidet die Begründung, nicht die Matrix. Die Entscheidungslogik ist damit in fünf Schritten beschreibbar: Erstens die technische Severity festhalten, gegebenenfalls mit CVSS-Vektor. Zweitens die Likelihood-Faktoren gegen die Ausgangslage des Tests lesen und als Stufe begründen. Drittens den Impact aus belegter Wirkung und Business-Kontext als Stufe begründen. Viertens die Kombination aus der Matrix ablesen und bei Doppelfeldern die ausschlaggebende Dimension benennen. Fünftens die Belegstufe und die daraus folgende Unsicherheit ausweisen. Pfadrisiken werden auf derselben Logik, aber als eigenes Element bewertet.
Risikostufen definieren
Die folgenden Stufen sind finale Risikostufen (Risk Rating) im konkreten Kundenkontext - nicht die technische Severity und nicht die CVSS-Severity. Sie entstehen aus Exposure, Exploitability, Voraussetzungen, wirksamen Kontrollen, Business Impact, Pfadbezug und Belegstufe; die technische Severity bleibt daneben als eigene Angabe im Finding stehen. Stufen sind nur dann konsistent anwendbar, wenn sie definiert sind - nicht als Schlagwort, sondern über typische Eigenschaften, typischen Impact und typische Voraussetzungen. Die Definitionen sind bewusst beschreibend und ohne Zahlenschwellen; eine falsche Präzision würde nur vortäuschen, dass die Einordnung mechanisch wäre.
| Risikostufe | Typische technische Eigenschaften | Typischer Impact | Typische Voraussetzungen | Abweichung von der technischen Severity |
|---|---|---|---|---|
| Informational | Keine belegte Sicherheitswirkung; Härtungspotenzial, Abweichung von Best Practice, Informationsabfluss ohne Hebel | Kein direkter Impact; kann Aufklärung erleichtern | Beliebig | Ein technisch "Low" bewertetes Banner kann hier landen, wenn keine Wirkung belegbar ist |
| Low | Begrenzte Wirkung, hohe Hürden oder unzuverlässige Ausnutzung; isolierte Fehlkonfiguration ohne weiterführenden Schritt | Geringer Schaden, leicht behebbar, keine sensiblen Daten | Oft Admin-Rechte, lokale Präsenz oder unwahrscheinliche Interaktion | Höher, wenn der Befund als Glied eines Pfads nachweislich weiterführt |
| Medium | Reale Ausnutzbarkeit mit spürbarer Wirkung; Zugriff auf interne Informationen oder eingeschränkte Rechte | Spürbarer, aber begrenzter Schaden; keine kritischen Datenklassen oder Prozesse | Standard-Nutzer oder Netzzugang; moderate Hürden | Niedriger bei belegter Preventive Control oder enger Exposition; höher bei breiter Exposition oder kritischem Pfadbezug |
| High | Zuverlässige Ausnutzung mit erheblicher Wirkung: Zugriff auf sensible Daten, Übernahme einzelner Systeme, Rechteausweitung | Erheblicher Schaden für Daten, Betrieb oder Pflichten; kritische Datenklassen betroffen | Geringe Hürden; aus dem Nutzernetz oder authentifiziert mit Standardkonto | Niedriger bei isoliertem System ohne produktive Daten und belegter Kontrolle; höher, wenn direkt ein Kernprozess oder Schutzziel erreicht wird |
| Critical | Zuverlässige, voraussetzungsarme Ausnutzung mit weitreichender Wirkung: breite Kompromittierung, Kontrolle über zentrale Systeme oder Identitäten | Schwerer Schaden für Kernprozesse, große Datenbestände oder die gesamte Umgebung | Keine oder minimale; aus dem Internet oder von jedem Arbeitsplatz | Niedriger praktisch nur bei belegt wirksamer Preventive Control und fehlender produktiver Relevanz - dann meist High, nicht niedriger |
Die letzte Spalte ist der Grund, warum die Risikostufe nie nur aus der technischen Severity oder dem CVSS-Wert folgt. Eine technisch kritische Schwachstelle landet beim Risk Rating "High", wenn Exposition und Kontrollen das rechtfertigen - und ein technisch mittlerer Befund ebenfalls bei "High", wenn er von jedem Arbeitsplatz aus ein Schutzziel erreicht. Die Risikostufe wird begründet, die Begründung nennt die Dimension, die den Ausschlag gegeben hat, und die technische Severity steht unverändert daneben.
Was gehört ins Finding?
Ein Finding trägt seine Bewertung vollständig in sich: Wer es liest, muss ohne Rückfrage verstehen, wie die Stufe zustande kam. Die Bewertungsinformationen ergänzen die Struktur aus dem Reporting-Deep-Dive; sie ersetzen sie nicht.
- Technische Severity: die Stufe der Schwachstelle an sich, vor jeder Kontextbetrachtung.
- CVSS, wo sinnvoll: Wert und Vektor; bei Umgebungsbezug mit Environmental-Anteil, als solcher gekennzeichnet.
- Voraussetzungen: was ein Angreifer mitbringen muss - Position, Rolle, Zugangsdaten, Interaktion.
- Exposure: wer das System erreichen kann, gelesen gegen die Ausgangslage des Tests.
- Business Impact: qualitativ, an die belegte Wirkung gebunden, mit Kennzeichnung dessen, was vom Auftraggeber kommt.
- Pfadbezug: ob und wo das Finding in einem Angriffspfad liegt - als Verweis auf das Pfadelement, nicht als Hochstufung.
- Vorhandene Kontrollen: welche berücksichtigt wurden, mit Typ und Beleg ihrer Wirkung; welche vorhanden, aber unwirksam waren.
- Begründung der finalen Risikoeinstufung: ein Satz, der die ausschlaggebenden Dimensionen nennt und die Belegstufe mit ihrer Unsicherheit ausweist.
Das Beispiel zeigt die Trennung in einer Zeile: "nicht Critical, da ..." ist die Information, die ein Reviewer oder Auftraggeber braucht, um die Stufe anzuzweifeln oder zu bestätigen. Die Art der Schwachstelle und ihre Testmethodik vertieft der API-Deep-Dive; hier zählt, dass die Bewertung für sich steht.
Typische Bewertungsfehler
- CVSS gleich Risiko setzen: Der Score wird als Einstufung übernommen, Kontext und Angriffspfad entfallen.
- Base Score blind übernehmen: Der Herstellerwert wird abgeschrieben, ohne Environmental-Kontext und ohne Prüfung, ob der verwundbare Codepfad hier überhaupt erreichbar ist.
- Theoretischen Maximal-Impact bewerten: "Könnte zu vollständiger Kompromittierung führen" ohne belegten Weg dorthin.
- Voraussetzungen ignorieren: Ein Befund, der Admin-Rechte braucht, wird wie ein unauthentifizierter behandelt - oder umgekehrt wird "authentifiziert" als Hürde gerechnet, obwohl jeder Mitarbeiter ein Konto hat.
- Internet- und interne Exposition gleich behandeln: In beide Richtungen falsch - intern ist keine Entwarnung, aber auch nicht automatisch dasselbe wie Internet.
- Vorhandene Kontrollen nur annehmen: "EDR vorhanden" wird risikosenkend gewertet, ohne dass der Agent im Test etwas bewirkt hat.
- Detection mit Prevention verwechseln: Ein Alarm wird gerechnet, als hätte er den Schritt verhindert.
- Attack Paths ignorieren: Alle Findings isoliert bewertet, die wichtigste Erkenntnis des Tests fehlt.
- Jedes Glied eines kritischen Pfads hochstufen: Die Severity-Logik wird inkonsistent, und die Pfadaussage geht in aufgeblähten Einzelbefunden unter.
- Business Impact erfinden: Euro-Beträge oder Prozessfolgen ohne Datenbasis des Auftraggebers.
- Scheingenauigkeit mit Dezimalstellen: Eine Bewertung mit "7,3" suggeriert eine Messung, wo eine begründete Einordnung stattgefunden hat.
- Gleiche Findings inkonsistent bewerten: Zwei vergleichbare Befunde mit verschiedenen Stufen, ohne dass Privilegien, Exposition oder Auswirkungen den Unterschied erklären.
- Belegstufe verschweigen: Ein identifizierter Befund wird wie ein verifizierter formuliert.
Bewertungs-Review vor Abgabe
Die Bewertung wird vor der Abgabe als eigener Arbeitsschritt geprüft - am besten von jemandem, der die Findings nicht selbst geschrieben hat. Die Checkliste ist kurz, weil sie bei jedem Bericht vollständig abgearbeitet werden soll:
- Gleiche Methodik überall: Jedes Finding wurde entlang derselben Dimensionen betrachtet; keines hat eine Stufe ohne Begründung.
- Gleiche Maßstäbe: Die Stufendefinitionen wurden einheitlich angewandt - gleiche Maßstäbe, nicht automatisch gleiche Stufen.
- Ausreißer prüfen: Jede Stufe, die nur über den Pfadbezug erklärbar ist, obwohl der Pfad nicht genannt wird; jede Stufe, die stark vom CVSS-Wert abweicht, ohne dass die Begründung die Abweichung trägt.
- Vergleichbare Findings vergleichen: Befunde derselben Klasse nebeneinanderlegen - unterscheiden sich die Stufen, muss der Unterschied aus Privilegien, Interaktion, Exposition oder Auswirkung hervorgehen.
- Pfad-Risiken separat prüfen: Jeder Pfad hat eine eigene Bewertung, die Glieder behalten ihre Severity, die Behebungswirkung je Glied ist benannt.
- Business Impact plausibilisieren: Jede Impact-Aussage ist an belegte Wirkung gebunden; was vom Auftraggeber stammt, ist als solches gekennzeichnet; keine erfundenen Zahlen.
- Unbewiesene Annahmen markieren: Jede berücksichtigte Kontrolle hat einen Beleg; jede Belegstufe unter 3 hat einen ausgewiesenen Vorbehalt.
Übergang zu Remediation
Die Risikobewertung ist kein Selbstzweck. Sie ist die Entscheidungsgrundlage für alles, was nach dem Bericht kommt: was zuerst behoben wird, welche Pfade zuerst unterbrochen werden, wo kurzfristige Kompensationsmaßnahmen sinnvoll sind, bis die eigentliche Behebung greift, und was im Retest priorisiert wird. Eine Priorisierung nach Pfadwirkung sieht dabei oft anders aus als eine nach Severity-Etikett: Die Maßnahme, die drei Pfade gleichzeitig unterbricht, steht vor dem isolierten "High" auf einem Testsystem. Wie Remediation geplant, kompensiert, nachgewiesen und im Retest belastbar bestätigt wird, ist Gegenstand des eigenen Deep-Dives zu Remediation und Retest. Hier endet der Beitrag bewusst dort, wo die Bewertung in die Entscheidung übergeht.
Häufige Fragen
Muss jedes Finding einen CVSS-Wert haben?
Nein. CVSS ist sinnvoll, wo es technische Vergleichbarkeit herstellt - bei bekannten Software-Schwachstellen und klar abgrenzbaren Schwachstellenklassen. Bei Fehlkonfigurationen, Berechtigungspfaden, Business-Logik-Fehlern und verketteten Befunden trägt der Vektor wenig; dort steht die begründete Einstufung entlang der Bewertungsdimensionen im Vordergrund. Wo CVSS verwendet wird, gehört der Vektor dazu, nicht nur die Zahl.
Darf eine technisch kritische Schwachstelle als Medium eingestuft werden?
Ja - auf der Ebene der finalen Risikoeinstufung, wenn die Begründung es trägt: enge Exposition, hohe reale Voraussetzungen, eine im Test belegt wirksame Preventive Control und fehlende produktive Relevanz. Die technische Severity bleibt dabei im Finding stehen und wird nicht überschrieben - der Leser sieht beides und die Begründung dazwischen. Ohne belegte Kontrolle und ohne enge Exposition bleibt es bei High oder Critical.
Senkt ein EDR-Alarm das Risiko?
Nicht die Ausnutzbarkeit - die bleibt, was sie ist. Das Gesamtrisiko kann sinken, wenn belegt ist, dass die Erkennung im Test ausgelöst hat und dass eine Reaktion möglich ist, bevor der Impact eintritt. Ein Alarm ohne nachgewiesene Reaktionsfähigkeit ist eine Beobachtung, keine risikosenkende Kontrolle.
Wie wird ein Angriffspfad bewertet, ohne die Einzelfindings hochzustufen?
Als eigenes Element mit eigener Bewertung auf Pfadebene - ein Path- beziehungsweise Business-Risk. Die Glieder behalten ihre Finding-Severity und verweisen auf den Pfad; der Pfad trägt die kritische Bewertung und benennt je Glied, ob dessen Behebung den Pfad unterbricht, erschwert oder nur den Impact begrenzt. So bleibt die Severity-Logik konsistent, und die Priorisierung folgt der Wirkung.