in diesem Beitrag<\/a>.<\/p>\n\n\n\nCVSS: Standard mit ungenutztem Potenzial<\/h2>\n\n\n\n CVSS ist der etablierte Standard zur Bewertung von Schwachstellen in Software und Systemen. Er wurde entwickelt, um Sicherheitsteams eine einheitliche und vergleichbare Grundlage für Priorisierungsentscheidungen zu liefern. Der CVSS beschreibt jede Schwachstelle aus drei Perspektiven:<\/p>\n\n\n\n
Der Base Score beschreibt die statischen, unveränderlichen Eigenschaften einer Schwachstelle. Er setzt sich zusammen aus der Bewertung, über welchen Weg die Schwachstelle ausgenutzt werden kann, wie komplex eine Ausnutzung ist, ob besondere Rechte erforderlich sind und welche Schutzziele in welchem Ausmaß von einer Ausnutzung betroffen sind. Der sich daraus ergebende Wert gilt unabhängig davon, in welcher Umgebung das betroffene System betrieben wird, und bildet die Grundlage für weitere Bewertungen.<\/p>\n\n\n\n
Der Temporal Score ist eine optionale Erweiterung, die den Base Score um zeitabhängige Faktoren ergänzt. Er bildet ab, ob bereits funktionierender Exploit-Code existiert, ein Patch verfügbar ist und wie verlässlich die vorliegenden Informationen zu einer Schwachstelle sind.
Der Environmental Score ist eine weitere optionale Erweiterung des Base Scores und entscheidend für die eigene Priorisierung. Er passt den Base Score an die reale Umgebung einer Organisation an und gewichtet, wie gut ein System durch vorhandene Schutzmaßnahmen abgeschirmt ist, wie kritisch die betroffene Komponente für den Betrieb ist und wie sensibel die verarbeiteten Daten sind. Im Gegensatz zum Temporal Score wird dieser nicht von außen gepflegt, sondern aktiv vom Nutzer konfiguriert.<\/p>\n\n\n\n
Trotz der Empfehlung des Forums of Incident Response and Security Teams, kurz FIRST, dass das CVSS entwickelt und pflegt, den Base Score nicht als alleinige Priorisierungsgrundlage zu nutzen, sieht die Realität oft anders aus. Temporal Score und Environmental Score bleiben in der Praxis zumeist unbeachtet, weil den meisten Organisationen die Werkzeuge für ihre systematische Anwendung fehlen. Der Environmental Score setzt voraus, dass für jedes Asset individuell bewertet wird, wie geschäftskritisch es ist, wie gut es geschützt ist und welche Daten es verarbeitet. Dieser Aufwand lässt sich für einzelne Schwachstellen manuell leisten, nicht jedoch für eine gesamte Datenbank von CVEs. Das Ergebnis ist eine Priorisierung, die auf einer theoretischen Worst-Case-Annahme beruht, statt auf dem realen Risikoprofil der eigenen Infrastruktur.<\/p>\n\n\n\n
9.8 < 3.4: Wenn Kontext mehr wiegt<\/h2>\n\n\n\n Wie groß der Unterschied zwischen der Risikobewertung auf Basis des Base Scores allein und der Ergänzung um den Environmental Score in der Praxis sein kann, zeigt ein konkretes Beispiel.<\/p>\n\n\n\n
Angenommen, der Datei-Server der Buchhaltung ist von einer Schwachstelle mit einem Base Score von 9.8 betroffen. Der Angriffsvektor ist netzwerkbasiert, die Komplexität niedrig, besondere Berechtigungen sind nicht erforderlich. Auf den ersten Blick klar kritisch.
Gleichzeitig ist in derselben Infrastruktur ein zweiter Server, der RDP-Server, von einer Schwachstelle mit einem Base Score von 3.4 betroffen. Er ist direkt aus dem Internet erreichbar, verarbeitet Zugangsdaten und verfügt über keine zusätzlichen Schutzmaßnahmen.<\/p>\n\n\n\n
Welche Schwachstelle sollte in diesem Szenario wirklich priorisiert werden?<\/strong><\/p>\n\n\n\nWas fehlerhafte Priorisierung kostet<\/h2>\n\n\n\n Wer bei seinem Schwachstellenmanagement den Kontext der eigenen Infrastruktur außen vor lässt, riskiert die folgenden Konsequenzen:<\/p>\n\n\n\n
\nErschöpfte Kapazitäten<\/strong>:Verzögerte Reaktionszeit<\/strong>:Regulatorisches Risiko<\/strong>:Environmental Score in Enginsight: systematisch statt manuell<\/h2>\n\n\n\n Was für einzelne Schwachstellen noch manuell leistbar ist, skaliert nicht auf eine gesamte Infrastruktur. Enginsight schließt diese Lücke und integriert die Environmental Score-Berechnung nach CVSS v3 direkt in die Plattform als konfigurierbares Feature für Hosts und Endpunkte, inklusive aller CVE-Ansichten und Berichte.<\/p>\n\n\n\n
Das Verfahren setzt auf ein kategorienbasiertes Modell mit Tag-Zuweisung. Umgebungsprofile werden einmal definiert und über Tags automatisch auf Assets angewendet. Wird ein neues System zur Infrastruktur hinzugefügt und mit dem passenden Tag versehen, erhält es sofort die zugehörige Environmental Score-Konfiguration, kurz ENVS, ohne manuelle Einzelbewertung.<\/p>\n\n\n\n
Gehört ein Asset mehreren Kategorien an, löst das System Konflikte automatisch nach einem transparenten Prioritätsmodell. Die Kategorie mit höherer Priorität gewinnt je Metrik. In der jeweiligen Asset-Detailansicht ist jederzeit ersichtlich, aus welcher Kategorie ein Metrik-Wert stammt.<\/p>\n\n\n\n
Sobald ein Environmental Score konfiguriert ist, wird er in CVE-Listen, Host- sowie Endpunkt-Übersichten und Berichten als primärer Schweregrad verwendet. Der CVSS-Basiswert bleibt daneben sichtbar, um Vergleichbarkeit zu gewährleisten.<\/p>\n\n\n\n
Du möchtest mehr über den Environmental Score in Enginisght erfahren? Dann wirf jetzt einen Blick in unsere Dokumentation<\/a>.<\/p>\n\n\n\nEnvironmental Score, ganz einfach umgesetzt<\/h2>\n\n\n\n Wie einfach sich eine realistische Einschätzung der eigenen IT-Landschaft mit Enginsight umsetzen lässt, zeigt ein Blick auf das oben genannte Beispiel. <\/p>\n\n\n\n
Für den Dateiserver Buchhaltung aus dem Beispiel erstellst du dazu einen ENVS-Manager unter Hosts mit dem Namen „Intern, geschützt“. Die Priorität regelt dabei, welcher ENVS-Manager greift, wenn ein System mehreren Kategorien zugeordnet ist. Da diese Kategorie das niedrigere Risikoprofil abbildet und sich im Konfliktfall mit anderen Kategorien nicht durchsetzen muss, bleibt die Priorität bei ihrem Standardwert von 50.<\/p>\n\n\n\nIm nächsten Schritt ordnest du die Referenzen zu, für die der Environmental Score gelten soll. Dafür gibst du entweder einzelne Hosts direkt an oder nutzt das Tag-System, um die Konfiguration automatisch auf alle Hosts mit dem entsprechenden Tag anzuwenden. Über Tags zugeordnete Systeme erhalten die Konfiguration auch dann, wenn sie erst später zur Infrastruktur hinzukommen.<\/p>\n\n\n\nAnschließend legst du den Environmental Score fest. Wähle dafür die gewünschten Werte im Bereich Impact Subscore-Modifizierung manuell per Klick aus. Deine Auswahl wird dabei automatisch als Vektor-String angezeigt, den du bei Bedarf auch direkt bearbeiten kannst. Im Beispiel des Datei-Servers Buchhaltung ergibt sich so CR:L\/IR:L\/AR:L, da ein Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit hier wenig geschäftskritisch wäre.<\/p>\n\n\n\nFür den RDP-Server aus dem Beispiel legst du nun einen zweiten ENVS-Manager unter Hosts an, bspw. mit dem Namen „Extern, exponiert“. Da der Server Zugangsdaten verarbeitet und über keine zusätzlichen Schutzmaßnahmen verfügt, setzt du die Priorität hier höher an als beim Dateiserver Buchhaltung, zum Beispiel auf 80.<\/p>\n\n\n\nAuch hier ordnest du die entsprechenden Referenzen zu, entweder direkt den betroffenen Host oder ein passendes Tag, falls mehrere vergleichbar exponierte Systeme diese Konfiguration teilen sollen.<\/p>\n\n\n\nDen Environmental Score legst du auch hier über die manuelle Auswahl im Bereich Impact Subscore-Modifizierung fest, angezeigt als Vektor-String. Im Beispiel des RDP-Servers ergibt sich so CR:H\/IR:H\/AR:M, da ein Verlust von Vertraulichkeit oder Integrität durch die verarbeiteten Zugangsdaten unmittelbar weitere Systeme gefährden würde, während zur Verfügbarkeit im Beispiel keine genaueren Angaben vorliegen. Ist ein Host beiden ENVS-Managern zugeordnet, entscheidet je Metrik die höhere Priorität, welcher ENVS-Manager durchgesetzt wird.<\/p>\n\n\n\nWas das in der Praxis bedeutet, zeigt sich unteranderem in der Sicherheitslücken-Übersicht. Hier stehen CVSS- und ENVS-Wert für jede Schwachstelle nebeneinander. Für den Dateiserver Buchhaltung sinkt der ENVS-Wert mit einer Bewertung von 7.8 entsprechend unter den CVSS-Basiswert von 9.8, sobald der ENVS-Manager aktiv ist. Während die Schwachstelle mit Base Score 3.4 auf dem RDP-Server nun mit einem ENVS-Wert von 8.1 deutlich höher priorisiert erscheint.<\/p>\n\n\n\nFür das Team bedeutet das zwei kurze Konfigurationen statt einer manuellen Einzelfallprüfung pro Host. Und kommen weitere Hosts hinzu, übernehmen sie durch die Zuordnung des passenden Tags automatisch die Konfiguration des entsprechenden ENVS-Managers.<\/p>\n\n\n\n
Fundierte Priorisierung statt Worst-Case-Annahmen<\/h2>\n\n\n\n Schwachstellenmanagement ist kein Ranking-Wettbewerb, bei dem der höchste Zahlenwert automatisch oben landet. Effektive Priorisierung bedeutet zu wissen, welche Schwachstelle in dieser Umgebung, auf diesem System und unter den vorhandenen Schutzmaßnahmen das höchste reale Risiko trägt.<\/p>\n\n\n\n
Der Environmental Score ist als fester Bestandteil von CVSS genau dafür entwickelt worden. Was bisher an Werkzeugen für seine systematische Anwendung fehlte, stellt Enginsight bereit. IT-Security-Teams können damit den vollen Umfang des Standards nutzen und Priorisierungsentscheidungen treffen, die auf dem realen Risikoprofil der eigenen Infrastruktur beruhen.<\/p>\n","protected":false},"excerpt":{"rendered":"
IT-Security-Teams arbeiten mit begrenzten Kapazitäten. Entwicklerzeit ist knapp, Wartungsfenster begrenzt und neue Schwachstellen erscheinen schneller, als bestehende geschlossen werden können. Unter diesen Voraussetzungen ist Priorisierung keine Frage des Komforts, sondern operative Notwendigkeit. Das meistgenutzte Werkzeug dafür ist der Common Vulnerability Scoring System Score, oder kurz: CVSS-Score. Was dabei selten hinterfragt wird, ist jedoch, dass CVSS […]<\/p>\n","protected":false},"author":31,"featured_media":38944,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[1],"tags":[],"class_list":["post-38922","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-inside-enginsight"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38922","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=38922"}],"version-history":[{"count":2,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38922\/revisions"}],"predecessor-version":[{"id":38941,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38922\/revisions\/38941"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/38944"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=38922"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=38922"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=38922"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-1.1-1-1024x314.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-1.2-1-1024x349.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-1.3-1-1024x411.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-2.1-1-1024x435.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-2.2-1-1024x342.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/ENVS-2.3-1-1024x412.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enginsight.com\/wp-content\/uploads\/envs-sicherheitsluecken-1-1024x307.png\")
<\/figure>\n\n\n\n