{"id":39021,"date":"2026-10-22T14:53:39","date_gmt":"2026-10-22T12:53:39","guid":{"rendered":"https:\/\/enginsight.com\/?p=39021"},"modified":"2026-10-22T14:53:41","modified_gmt":"2026-10-22T12:53:41","slug":"environmental-score-schwachstellen-priorisieren","status":"publish","type":"post","link":"https:\/\/enginsight.com\/de\/blog\/environmental-score-schwachstellen-priorisieren\/","title":{"rendered":"Schwachstellen priorisieren mit dem Environmental Score: Hosts nach ihrem Wert f\u00fcr den Betrieb bewerten"},"content":{"rendered":"
\n
\n <\/path><\/svg>\n <\/div>\n
\n

Der Praxisleitfaden für den Environmental Score bei Enginsight<\/p>\n

Mit 220 Hosts reicht es nicht mehr, Schwachstellen nach der höchsten CVSS-Zahl abzuarbeiten. In Teil 3 unseres Praxisleitfadens zeigen wir, wie Systeme nach Vertraulichkeit, Integrität und Verfügbarkeit bewertet werden und diese Bewertung als Environmental Score hinterlegt wird. Danach steht oben auf der Liste, was für den Betrieb am meisten zählt.<\/p>\n <\/div>\n<\/div>\n\n\n\n

Environmental Score: Teil 3 des Praxisleitfadens für Enginsight<\/h2>\n\n\n\n

Die Liste wächst schneller als die Wartungsfenster<\/h3>\n\n\n\n

Dienstagmorgen in Jena. Seit Teil 2<\/a> ist einiges passiert. Die Firma ist kräftig gewachsen, in Hamburg gibt es einen dritten Standort, und aus rund 150 Hosts sind 220 geworden. Der neue ERP-Server (Enterprise Resource Planning) läuft im Echtbetrieb, der Fileserver mit den Vertragsdaten steht unter File Integrity Monitoring. Für IT-Admin Andreas heißt das vor allem eins: mehr Software auf mehr Systemen und damit mehr Schwachstellen.<\/p>\n\n\n\n

Sein Vorgehen war bisher einfach. Er hat die Liste der offenen Schwachstellen nach dem CVSS-Wert (Common Vulnerability Scoring System) sortiert und von oben nach unten gepatcht. Bei 150 Hosts ging das auf. An diesem Morgen stehen 1.260 offene Einträge auf der Liste, 214 davon mit einem CVSS-Wert ab 9.0. Jede Woche kommt mehr dazu, als Andreas schließen kann.<\/p>\n\n\n\n

Dazu kommt die allgemeine Lage. Das BSI hat zwischen Juli 2024 und Juni 2025 im Schnitt 119 neue Schwachstellen pro Tag gezählt, rund 24 Prozent mehr als im Berichtszeitraum davor (BSI, „Die Lage der IT-Sicherheit in Deutschland 2025“, veröffentlicht am 11.11.2025). Für Andreas wird das langsam zu viel. Er fühlt den wachsenden Druck zu handeln.<\/p>\n\n\n\n

Was der CVSS-Wert über Ihren Betrieb weiß<\/h3>\n\n\n\n

Beim Durchsehen in der Enginsight-Plattform fällt Andreas etwas auf. Ganz oben steht eine Schwachstelle mit einem CVSS-Wert von 9.8 in einer Software, die auf den 33 Laptops des Hamburger Vertriebsteams installiert ist. Weiter unten, bei 7.5, steht eine Schwachstelle im Datenbankdienst des ERP-Servers. Mit ihr kann ein Angreifer den Dienst lahmlegen. Fällt ein Vertriebslaptop aus, ist das nicht weiter schlimm. Dann weist Andreas ein Ersatzgerät zu. Fällt aber das ERP aus, bekommt die Fertigung in Jena keine Aufträge mehr, und an keinem der drei Standorte lässt sich ein Lieferschein schreiben. Hier zeigt sich ein Problem, das gerade im wachsenden Mittelstand virulent ist: Der CVSS alleine – genauer gesagt: sein Base Score – hilft nicht weiter, wenn es darum geht, viele Systeme zu verwalten, wenn eine für den Betrieb gefährlichere Schwachstelle nachrangig behandelt wird.<\/p>\n\n\n\n

Der CVSS-Basiswert (Base Score) beschreibt die Schwachstelle selbst: wie sie ausgenutzt wird und was sie im schlimmsten Fall anrichtet. Man kann sich die Einordnung in etwa so vorstellen: Man stellt bei Nacht einen Pott voll Gold auf einen unbewachten, nicht abgeschlossenen Parkplatz in einer düsteren Gegend, von der man nicht weiß, ob sich viele Kriminelle dort herumtreiben und bewertet wie sicher das dann ist. Der Base Score ist eine Art Worst-Case-Szenario.<\/p>\n\n\n\n

Über den Host, auf dem die Schwachstelle sitzt, sagt der Basiswert nichts. Das ist so gewollt, denn eine Datenbank für CVEs (Common Vulnerabilities and Exposures) kennt Ihr Unternehmen nicht. Deswegen hat die CVSS Special Interest Group (SIG) in ihrem CVSS-3.1-Standard noch zwei weitere Scores definiert, nämlich den Temporal Score und den Environmental Score. Kurz gesprochen, gibt der Temporal Score an, ob schon Exploit-Code im Umlauf ist oder ob ein Patch bereitsteht. Der Environmental Score bildet ab, wie eine Schwachstelle in einem konkreten Unternehmen wirkt.<\/p>\n\n\n\n

Und das ist nun interessant, denn mit dem Environmental Score legt die Organisation, die ein System betreibt, selbst fest, wie schwer sie ein Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit trifft. Diese drei Schutzziele kennen viele als CIA-Triade (Confidentiality, Integrity, Availability).<\/p>\n\n\n\n

Andreas wird klar: Er muss priorisieren, und dafür braucht er Wissen, das in keiner Datenbank steht. Welche Systeme müssen laufen, damit der Betrieb weitergeht? Welche Daten dürfen auf keinen Fall nach draußen? Die Antworten darauf haben andere im Haus.<\/p>\n\n\n\n

In der Enginsight-Plattform hinterlegt man diese Bewertung im Environmental Score-Manager, kurz ENVS-Manager. Wie Base Score, Temporal Score und Environmental Score im CVSS zusammenhängen, steht ausführlich im Beitrag Priorisierung mit Kontext: Wie Enginsight den Environmental Score nutzbar macht<\/a>. Aber was bedeuten die einzelnen Parameter nun für einen Betrieb tatsächlich und wie legt man sie sinnvoll fest, dass am Ende eine für das Unternehmen brauchbare Prioritätsliste erscheint? Das klären wir nun.<\/p>\n\n\n\n

Schritt 1: Den Schutzbedarf mit Geschäftsleitung und Technik klären<\/h2>\n\n\n\n

Andreas setzt einen Termin von 90 Minuten an. Mit am Tisch sitzen Herr Dr. Rüdiger aus der Geschäftsleitung, der das Geschäftsrisiko verantwortet, und Technikchefin Frau Gruber, die Konstruktion und Fertigung leitet. Andreas bringt die Hostliste aus der Plattform mit, sortiert nach den Tags aus Teil 1<\/a>.<\/p>\n\n\n\n

Für jede Gruppe von Systemen stellen die drei dieselben Fragen:<\/p>\n\n\n\n