Die unbekannte IT: Warum Unternehmen Sicherheitslücken nicht rechtzeitig erkennen und das Problem oft im Asset Management liegt

Eine kritische Sicherheitslücke wird veröffentlicht. Sicherheitsmeldungen erscheinen, Hersteller veröffentlichen Warnungen und IT-Verantwortliche prüfen, welche Systeme betroffen sein könnten. Die ersten Fragen sind eigentlich einfach: Welche Software setzen wir ein? Welche Systeme verwenden die betroffene Komponente? Wo laufen diese Systeme? Wer ist verantwortlich? Und wie schnell können wir reagieren?

In einem gut organisierten Unternehmen lassen sich diese Fragen innerhalb kurzer Zeit beantworten. Die verantwortlichen Teams können die betroffenen Anwendungen identifizieren, ihre Kritikalität bewerten und geeignete Maßnahmen einleiten. In anderen Organisationen beginnt dagegen zunächst eine Suche, die mitunter länger dauert als die eigentliche technische Behebung der Schwachstelle. Unterschiedliche Abteilungen durchsuchen Tabellen, Dienstleister werden kontaktiert, alte Projektdokumentationen hervorgeholt und einzelne Mitarbeitende gefragt, ob sie sich noch an bestimmte Systeme erinnern. Mitunter wird die komplette Infrastruktur zunächst händisch analysiert, weil niemand so richtig weiß ob die betroffene Sicherheitslücke auf einem der Systeme installiert ist.

Das eigentliche Problem ist dann häufig nicht allein die Sicherheitslücke. Es ist die fehlende Transparenz über die eigene IT-Landschaft. Ein Unternehmen kann noch so viele Sicherheitswerkzeuge einsetzen. Wenn es nicht zuverlässig weiß, welche Hardware, Software, Cloud-Dienste und digitalen Komponenten tatsächlich im Einsatz sind, bleibt ein wesentlicher Teil seiner Angriffsfläche möglicherweise unentdeckt.

Das britische National Cyber Security Centre (NCSC) beschreibt ein vollständiges und aktuelles Asset-Inventar als grundlegende Voraussetzung für wirksame Cybersicherheit. Nur wenn Unternehmen ihre Systeme kennen und Verantwortlichkeiten festlegen, können sie Schwachstellen zuverlässig zuordnen und angemessen behandeln. Auch das National Institute of Standards and Technology (NIST) verankert Asset Management im Cybersecurity Framework 2.0 als eigenständigen Bestandteil der Identifizierung und Steuerung von Cyberrisiken.

Die entscheidende Erkenntnis lautet: Unternehmen können ihre IT nicht zuverlässig schützen, wenn sie keinen belastbaren Überblick über ihre digitalen Vermögenswerte besitzen.

Genau deshalb verdient Asset Management eine deutlich größere Aufmerksamkeit, als ihm in vielen Organisationen zugestanden wird. Es ist nicht bloß Inventarverwaltung für die IT-Abteilung. Es ist eine wesentliche Grundlage für Sicherheitsentscheidungen, Risikomanagement, Notfallplanung und den wirtschaftlichen Betrieb digitaler Geschäftsprozesse.

Das eigentliche Problem: Unternehmen schützen eine IT-Landschaft, die sie nicht vollständig kennen

Die IT-Landschaft eines modernen Unternehmens besteht längst nicht mehr nur aus Servern, Arbeitsplatzrechnern und installierter Standardsoftware. Hinzu kommen virtuelle Maschinen, Container, Cloud-Ressourcen, SaaS-Anwendungen, Schnittstellen, externe Dienste, mobile Geräte, Netzkomponenten und Softwarebibliotheken. Viele dieser Komponenten werden automatisiert bereitgestellt, regelmäßig verändert oder von unterschiedlichen Teams und Dienstleistern betrieben.

Diese Entwicklung hat erhebliche Vorteile. Neue Anwendungen können schneller bereitgestellt werden, Fachbereiche können flexibler arbeiten und technische Ressourcen lassen sich bedarfsgerecht skalieren. Gleichzeitig steigt jedoch die Komplexität der Bestandsverwaltung. Ein System, das gestern noch nicht existierte, kann heute produktive Geschäftsdaten verarbeiten. Eine Anwendung, die vor Jahren für ein einzelnes Projekt entwickelt wurde, kann noch immer öffentlich erreichbar sein. Und eine Softwarekomponente kann über mehrere Anwendungen verteilt genutzt werden, ohne dass ihre Abhängigkeiten zentral dokumentiert sind.

Das Problem verschärft sich, wenn die Informationen über diese Systeme auf verschiedene Quellen verteilt sind. Die IT-Abteilung führt möglicherweise eine Hardwareliste, das Lizenzmanagement pflegt eine eigene Datenbank, die Informationssicherheit verwendet ein Schwachstellenwerkzeug und der Einkauf dokumentiert externe Dienstleister in einem separaten System. Jede dieser Informationsquellen kann für sich genommen sinnvoll sein. Wenn sie jedoch nicht zusammengeführt werden, entsteht kein vollständiges Bild der tatsächlichen IT-Landschaft.

Das ist keineswegs nur ein theoretisches Risiko. Das NCSC weist ausdrücklich darauf hin, dass Asset Management Hardware, Software, virtuelle Infrastruktur, Informationen und Onlinekonten berücksichtigen sollte. Entscheidend ist nicht die bloße Existenz einer Liste, sondern die Qualität der Informationen und ihre Nutzbarkeit für operative Entscheidungen.

Wie unbekannte Systeme zum Sicherheitsrisiko werden

Stellen wir uns ein mittelständisches Unternehmen vor, das seine Kundenplattform modernisiert hat. Die neue Anwendung läuft auf einer aktuellen Infrastruktur, wird regelmäßig aktualisiert und durch etablierte Sicherheitsmaßnahmen geschützt. Parallel existiert jedoch noch eine ältere Verwaltungsanwendung, die ursprünglich für einen begrenzten Zeitraum eingerichtet wurde.

Diese Anwendung wird nur selten verändert. Ihr ursprünglicher Projektverantwortlicher hat das Unternehmen verlassen, die technische Dokumentation ist unvollständig und die Anwendung taucht im zentralen Systeminventar nicht mehr auf. Dennoch ist sie weiterhin erreichbar und verarbeitet Daten, die für den Geschäftsbetrieb relevant sind.

Wird nun eine Sicherheitslücke in einer verwendeten Softwarekomponente bekannt, konzentriert sich die Untersuchung zunächst auf die offiziell dokumentierten Systeme. Die alte Anwendung bleibt möglicherweise unberücksichtigt. Das Unternehmen glaubt, die Betroffenheit geprüft zu haben, obwohl tatsächlich nur ein Teil seiner IT-Landschaft untersucht wurde.

Genau darin liegt die Gefahr: Ein unvollständiges Inventar kann ein falsches Gefühl von Sicherheit erzeugen.

Ein Sicherheitsbericht, der keine betroffenen Systeme ausweist, ist nur so aussagekräftig wie die Bestandsdaten, auf denen er beruht. Fehlende Treffer können bedeuten, dass keine betroffene Komponente vorhanden ist. Sie können aber ebenso bedeuten, dass das betreffende System gar nicht untersucht wurde.

Unternehmen müssen deshalb zwischen zwei Aussagen unterscheiden: „Wir haben keine betroffenen Systeme gefunden“ und „Wir haben nachweislich alle relevanten Systeme überprüft und keine betroffenen Komponenten identifiziert“. Nur die zweite Aussage bietet eine belastbare Grundlage für eine Risikobewertung.

Was Asset Management wirklich bedeutet

Asset Management wird häufig mit einer Inventarliste verwechselt. Eine solche Liste ist wichtig, reicht allein aber nicht aus. Professionelles IT Asset Management umfasst die systematische Identifizierung, Dokumentation, Klassifizierung und Verwaltung digitaler und technischer Ressourcen über ihren gesamten Lebenszyklus hinweg.

Dazu gehört nicht nur die Frage, welche Geräte und Anwendungen existieren. Ebenso wichtig ist, wo sie eingesetzt werden, welche Geschäftsprozesse von ihnen abhängen, welche Softwareversionen verwendet werden und wer für ihren Betrieb verantwortlich ist. Darüber hinaus müssen Abhängigkeiten zwischen Systemen nachvollziehbar sein. Eine Anwendung kann beispielsweise auf einer bestimmten Datenbank, einem zentralen Identitätsdienst, einer externen API und einer gemeinsam genutzten Softwarebibliothek beruhen.

Ein belastbares Asset Management verbindet diese Informationen zu einer verwertbaren Sicht auf die IT-Landschaft. Es schafft damit die Voraussetzung, technische Risiken mit ihrer geschäftlichen Bedeutung zu verknüpfen. Das ist ein wesentlicher Unterschied zwischen einer reinen Bestandsverwaltung und einem strategischen IT-Management.

Das NIST empfiehlt im Cybersecurity Framework 2.0 unter anderem, Inventare für Hardware, Software, Dienste und Systeme zu führen, Lieferantendienste zu erfassen und Assets entsprechend ihrer Kritikalität zu priorisieren. Außerdem sollen Systeme und Daten über ihren Lebenszyklus hinweg verwaltet werden.

Welche Informationen ein sinnvolles Asset-Inventar enthalten sollte

Ein Asset-Inventar muss nicht für jedes System dieselbe Detailtiefe besitzen. Ein geschäftskritischer Server benötigt beispielsweise andere Informationen als ein wenig kritischer Testrechner. Dennoch sollten bestimmte Grundinformationen systematisch erfasst werden.

• Eindeutige Identifikation: Jedes Asset benötigt eine nachvollziehbare Kennung, beispielsweise einen Hostnamen, eine Geräte-ID, eine Cloud-Ressourcen-ID oder eine eindeutige Anwendungskennung. Ohne eindeutige Identifikation entstehen schnell doppelte Einträge und Verwechslungen zwischen Entwicklungs-, Test- und Produktivsystemen. Gerade bei Sicherheitsmeldungen ist es entscheidend, eine betroffene Komponente eindeutig einem konkreten System zuordnen zu können. Die Identifikation sollte deshalb möglichst automatisiert und über verschiedene Werkzeuge hinweg konsistent erfolgen. Wo unterschiedliche Systeme verschiedene Kennungen verwenden, muss eine verlässliche Zuordnung möglich sein.
• Technische Informationen: Dazu gehören Hersteller, Produkt, Version, Betriebssystem, Installationsort und relevante Konfigurationen. Je nach Asset sind auch Softwareabhängigkeiten, Netzwerkexposition und eingesetzte Bibliotheken relevant. Diese Informationen helfen dabei, die Betroffenheit bei neu bekannt gewordenen Schwachstellen zu prüfen. Sie sollten möglichst aus technischen Datenquellen stammen und nicht ausschließlich auf manuellen Angaben beruhen. Veraltete Versionsinformationen können sonst dazu führen, dass eine Schwachstelle fälschlich ausgeschlossen oder ein nicht betroffenes System unnötig bearbeitet wird.
• Verantwortlichkeiten: Für jedes relevante Asset muss nachvollziehbar sein, wer fachlich verantwortlich ist und wer den technischen Betrieb übernimmt. Diese Rollen können bei einer Anwendung auseinanderfallen. Der Fachbereich verantwortet möglicherweise den Geschäftsprozess, während ein interner IT-Dienstleister die Infrastruktur betreibt und ein externer Anbieter die Anwendung wartet. Ohne klare Zuständigkeiten können selbst eindeutig erkannte Sicherheitsprobleme unbearbeitet bleiben. Die Verantwortlichkeiten müssen deshalb so dokumentiert werden, dass im Ernstfall unmittelbar die richtigen Personen erreicht werden.
• Geschäftliche Kritikalität: Nicht jedes Asset hat denselben Einfluss auf das Unternehmen. Ein System, das zentrale Kundenprozesse ermöglicht, muss anders bewertet werden als eine isolierte Testumgebung ohne produktive Daten. Für die Einstufung sind beispielsweise Verfügbarkeit, Vertraulichkeit, Integrität, gesetzliche Anforderungen und mögliche finanzielle Folgen relevant. Die Kritikalität sollte sich aus nachvollziehbaren Kriterien ergeben und nicht allein aus der technischen Einschätzung einzelner Administratoren. Nur dann können Sicherheitsmaßnahmen sinnvoll priorisiert werden.
• Lebenszyklus und Supportstatus: Ein Asset muss als geplant, aktiv, in Wartung, außer Betrieb oder zur Stilllegung vorgesehen erkennbar sein. Ebenso wichtig ist, ob Hersteller noch Sicherheitsupdates bereitstellen. Nicht mehr unterstützte Betriebssysteme und Anwendungen können zusätzliche Risiken verursachen, selbst wenn keine neue Schwachstelle gemeldet wurde. Lebenszyklusinformationen ermöglichen es, Ablösungen rechtzeitig zu planen und Sicherheitsrisiken nicht erst bei einer akuten Warnmeldung zu entdecken. Die Stilllegung muss außerdem technisch überprüft werden, damit tatsächlich keine unkontrollierten Systeme zurückbleiben.
• Abhängigkeiten und Datenflüsse: Eine Anwendung steht selten isoliert. Sie kommuniziert mit Datenbanken, Identitätsdiensten, APIs und weiteren Systemen. Diese Beziehungen müssen zumindest für kritische Anwendungen nachvollziehbar sein. Erst dadurch lässt sich beurteilen, welche Auswirkungen eine Schwachstelle auf nachgelagerte Systeme oder Geschäftsprozesse haben kann. Abhängigkeiten sind außerdem entscheidend, wenn eine Komponente vorübergehend abgeschaltet oder durch eine alternative Lösung ersetzt werden muss.

Ein solches Inventar ist keine einmalige Dokumentationsaufgabe. Es muss laufend aktualisiert werden, damit Veränderungen der IT-Landschaft nicht unbemerkt bleiben.

Warum klassische Inventarlisten in dynamischen IT-Umgebungen versagen

Viele Unternehmen besitzen bereits Inventarlisten, Asset-Management-Systeme oder Configuration Management Databases (CMDBs). Trotzdem gelingt es ihnen nicht immer, die tatsächliche IT-Landschaft vollständig abzubilden. Der Grund liegt häufig darin, dass Bestandsdaten aus unterschiedlichen Prozessen entstehen, unterschiedlich schnell aktualisiert werden und verschiedene Zwecke erfüllen.

Eine Einkaufsliste dokumentiert beispielsweise beschaffte Hardware, sagt aber nicht zwingend aus, ob das Gerät noch aktiv genutzt wird. Eine Softwarelizenzverwaltung zeigt, welche Lizenzen erworben wurden, beweist aber nicht, welche Versionen tatsächlich installiert sind. Ein Monitoring-System erkennt laufende Dienste, kennt aber möglicherweise weder deren geschäftliche Bedeutung noch den zuständigen Prozessverantwortlichen.

Das bedeutet nicht, dass diese Systeme ungeeignet wären. Vielmehr erfüllen sie unterschiedliche Aufgaben. Die Herausforderung besteht darin, ihre Informationen so zusammenzuführen, dass ein konsistentes und möglichst aktuelles Gesamtbild entsteht.

Schatten-IT: Wenn Systeme außerhalb der offiziellen Prozesse entstehen

Schatten-IT bezeichnet technische Ressourcen und Anwendungen, die außerhalb der vorgesehenen IT-Governance eingeführt oder betrieben werden. Das kann ein eigenständig beschaffter SaaS-Dienst sein, eine kleine Cloud-Instanz für ein Projekt oder eine Anwendung, die ein Fachbereich ohne ausreichende Abstimmung mit der IT einrichtet.

Nicht jede solche Initiative ist automatisch gefährlich. Mitarbeitende versuchen häufig, praktische Probleme zu lösen, wenn offizielle Prozesse zu langsam sind oder geeignete Werkzeuge fehlen. Das Risiko entsteht dann, wenn diese Anwendungen produktive Daten verarbeiten, dauerhaft betrieben werden und weder dokumentiert noch angemessen abgesichert sind.

Besonders problematisch sind Anwendungen, deren Existenz nur noch einzelnen Beschäftigten bekannt ist. Wenn diese Personen die Abteilung wechseln oder das Unternehmen verlassen, gehen nicht selten auch Informationen über technische Abhängigkeiten, Zugangsmöglichkeiten und betriebliche Besonderheiten verloren.

Eine wirksame Strategie sollte deshalb nicht ausschließlich auf Verbote setzen. Sie muss auch Wege schaffen, über die neue Anwendungen kontrolliert eingeführt und in die regulären Betriebsprozesse integriert werden können. Dazu gehören nachvollziehbare Beschaffungsprozesse, technische Freigaben, klare Verantwortlichkeiten und eine möglichst einfache Erfassung neuer Assets.

Cloud und SaaS: Die Infrastruktur ist nicht mehr vollständig sichtbar

Cloud-Dienste und Software-as-a-Service verändern die Art, wie Unternehmen ihre IT verwalten müssen. Ein Teil der technischen Infrastruktur wird vom Anbieter betrieben, während der Kunde für andere Aspekte wie Konfiguration, Identitäten, Datenzugriffe und die sichere Nutzung verantwortlich bleibt.

Hinzu kommt, dass Cloud-Ressourcen häufig automatisiert erstellt und wieder entfernt werden. Entwicklungsumgebungen, temporäre Testsysteme oder kurzlebige Container können entstehen, ohne dass sie in einer klassischen Inventarliste zeitnah erscheinen. Bei SaaS-Anwendungen fehlt Unternehmen zudem teilweise der direkte Zugriff auf die technische Infrastruktur, obwohl sie für die sichere Nutzung der Anwendung verantwortlich bleiben.

Deshalb muss Asset Discovery mehrere Ebenen abdecken. Dazu gehören technische Erkennung, Informationen aus Cloud-Plattformen, Softwareinventarisierung, Identitätsdaten und Beschaffungsinformationen. Keine einzelne Datenquelle liefert zwangsläufig einen vollständigen Überblick.

Gerade bei kritischen Anwendungen ist es wichtig, die Ergebnisse verschiedener Quellen abzugleichen. Ein System sollte nicht allein deshalb als unkritisch gelten, weil es in einer bestimmten Inventarliste fehlt.

Schwachstellenmanagement beginnt vor dem ersten Sicherheitsscan

Schwachstellenmanagement, häufig als Vulnerability Management bezeichnet, umfasst den Prozess, technische Schwachstellen zu identifizieren, zu bewerten, zu priorisieren und angemessen zu behandeln. Dazu gehören unter anderem Sicherheitsupdates, Konfigurationsänderungen, technische Schutzmaßnahmen und gegebenenfalls die Stilllegung betroffener Systeme.

Ein häufiger Irrtum besteht darin, Schwachstellenmanagement hauptsächlich mit Scannern und Patch-Management gleichzusetzen. Diese Werkzeuge sind wichtig, lösen aber nicht das gesamte Problem. Ein Scanner kann nur die Systeme und Komponenten untersuchen, die er tatsächlich erreicht oder deren Informationen ihm zur Verfügung stehen. Ein Patch-Management-System kann Updates nur dort zuverlässig ausrollen, wo die betroffenen Geräte und Softwareinstallationen bekannt und administrierbar sind.

Das britische NCSC empfiehlt deshalb ausdrücklich, zunächst die eingesetzten Systeme und Softwarekomponenten zu identifizieren und die jeweiligen Verantwortlichkeiten zu klären. Asset Discovery ist dabei kein einmaliger Schritt, sondern ein kontinuierlicher Prozess.

Der Zusammenhang zwischen Inventar, Schwachstelle und Maßnahme

Ein wirksamer Prozess lässt sich in mehreren aufeinander aufbauenden Schritten darstellen.

1. Assets identifizieren. Das Unternehmen erfasst die relevanten Hardware-, Software-, Cloud- und Anwendungsressourcen. Automatisierte Erkennung wird mit Informationen aus Beschaffung, Betrieb und Entwicklung kombiniert. Unbekannte oder nicht eindeutig zugeordnete Systeme werden als offene Punkte behandelt, statt sie stillschweigend auszublenden. Ziel ist ein belastbarer Überblick über die tatsächlich vorhandene IT-Landschaft.
2. Betroffenheit feststellen. Sobald eine Schwachstelle bekannt wird, prüft das Unternehmen, welche Assets die betroffene Software oder Komponente einsetzen. Dabei müssen Produktversionen, Konfigurationen und gegebenenfalls technische Voraussetzungen berücksichtigt werden. Bei Softwarebibliotheken ist auch die Abhängigkeit innerhalb von Anwendungen relevant. Eine oberflächliche Suche nach einem Produktnamen kann unzureichend sein, wenn die verwundbare Komponente indirekt eingebunden wird.
3. Risiko bewerten. Der technische Schweregrad einer Schwachstelle ist ein wichtiger Ausgangspunkt, aber nicht das alleinige Entscheidungskriterium. Entscheidend sind unter anderem die tatsächliche Erreichbarkeit des Systems, die Bedeutung der verarbeiteten Daten, mögliche Auswirkungen auf Geschäftsprozesse und Hinweise auf aktive Ausnutzung. Auch vorhandene Schutzmaßnahmen und die Möglichkeit einer wirksamen Eindämmung müssen berücksichtigt werden. Das Ergebnis sollte eine nachvollziehbare Priorisierung sein.
4. Maßnahmen festlegen. Je nach Situation kann ein Sicherheitsupdate erforderlich sein. In anderen Fällen müssen Konfigurationen angepasst, Zugänge eingeschränkt oder Systeme vorübergehend isoliert werden. Wenn keine geeignete Korrektur verfügbar ist, können kompensierende Schutzmaßnahmen notwendig werden. Die Entscheidung sollte dokumentiert werden und einen Verantwortlichen sowie einen verbindlichen Termin erhalten.
5. Umsetzung verifizieren. Eine abgeschlossene Aufgabe ist nicht automatisch ein Nachweis dafür, dass die Schwachstelle tatsächlich behoben wurde. Das Unternehmen sollte prüfen, ob das Update erfolgreich installiert wurde, ob die betroffene Komponente nicht mehr vorhanden ist oder ob eine alternative Maßnahme wirksam greift. Offene Ausnahmen müssen dokumentiert und regelmäßig neu bewertet werden. Erst die Verifikation schafft eine belastbare Grundlage für den Abschluss des Vorgangs.

Dieser Ablauf verdeutlicht, warum Asset Management und Schwachstellenmanagement eng miteinander verbunden sein müssen. Das eine liefert die Informationen über die vorhandene IT-Landschaft, das andere verarbeitet diese Informationen zu konkreten Sicherheitsmaßnahmen.

Nicht jede Sicherheitslücke ist gleich kritisch

Unternehmen erhalten regelmäßig Sicherheitsmeldungen zu Betriebssystemen, Anwendungen, Bibliotheken und technischen Komponenten. Die Herausforderung besteht nicht nur darin, möglichst viele Schwachstellen zu erkennen. Entscheidend ist, die relevanten Risiken zu identifizieren und die verfügbaren Ressourcen auf die wirksamsten Maßnahmen zu konzentrieren.

Der CVSS-Wert, also der Common Vulnerability Scoring System Score, kann helfen, den technischen Schweregrad einer Schwachstelle einzuordnen. Er bildet jedoch nicht automatisch das konkrete Risiko für ein bestimmtes Unternehmen ab. Zwei Systeme können dieselbe Schwachstelle aufweisen und trotzdem unterschiedliche Prioritäten erfordern.

Ein öffentlich erreichbarer Server mit sensiblen Kundendaten kann beispielsweise eine deutlich größere Gefährdung darstellen als eine isolierte Testumgebung, die keine produktiven Daten enthält. Umgekehrt darf eine interne Anwendung nicht allein deshalb als ungefährlich eingestuft werden, weil sie nicht direkt aus dem Internet erreichbar ist. Interne Systeme können über andere kompromittierte Komponenten oder gestohlene Zugangsdaten angegriffen werden.

Die CISA empfiehlt Unternehmen, ihren Katalog bekannter, aktiv ausgenutzter Schwachstellen, den sogenannten Known Exploited Vulnerabilities Catalog, als wichtigen Input für die Priorisierung zu verwenden. Er hilft dabei, Schwachstellen zu erkennen, für die konkrete Hinweise auf eine Ausnutzung in der Praxis vorliegen.

Ein praktikables Modell zur Risikopriorisierung

Für die betriebliche Bewertung sollten mehrere Dimensionen gemeinsam betrachtet werden.

Die Bewertung sollte nicht in einer beliebigen Punktesumme enden, die eine scheinbar objektive Entscheidung suggeriert. Für besonders kritische Fälle sind definierte Eskalationsregeln und fachliche Entscheidungen erforderlich. Ein Unternehmen muss nachvollziehbar erklären können, warum eine Schwachstelle sofort behandelt wird, während eine andere unter kontrollierten Bedingungen später bearbeitet werden kann.

Dafür benötigt es aktuelle Asset-Daten, technische Informationen und ein gemeinsames Verständnis von Risiko. Fehlen diese Grundlagen, wird die Priorisierung schnell zum Ratespiel.

Warum Verantwortlichkeiten mindestens so wichtig sind wie technische Werkzeuge

Selbst ein vollständiges Inventar und ein leistungsfähiger Scanner lösen ein organisatorisches Problem nicht automatisch: Wer muss handeln, wenn eine Schwachstelle entdeckt wird?

In vielen Unternehmen sind Betrieb, Informationssicherheit, Softwareentwicklung und Fachbereiche auf unterschiedliche Teams verteilt. Diese Aufteilung ist grundsätzlich sinnvoll, weil die Aufgaben unterschiedliche Kompetenzen erfordern. Sie wird jedoch zum Problem, wenn niemand für die gesamte Bearbeitungskette verantwortlich ist.

Die Informationssicherheit entdeckt eine Schwachstelle und erstellt einen Bericht. Der IT-Betrieb sieht sich für den betroffenen Server zuständig, kennt aber die geschäftliche Bedeutung der Anwendung nicht. Der Fachbereich wiederum kann die Auswirkungen eines Updates auf seinen Prozess einschätzen, hat aber keinen Zugriff auf die technische Umsetzung. Währenddessen bleibt unklar, wer eine verbindliche Entscheidung trifft und bis wann die Maßnahme abgeschlossen sein muss.

Eine wirksame Organisation benötigt deshalb klar definierte Rollen. Dazu gehören mindestens die fachliche Verantwortung für kritische Anwendungen, die technische Betriebsverantwortung, die Zuständigkeit für Sicherheitsbewertung und Eskalation sowie eine Instanz, die bei Zielkonflikten entscheidet.

Was im Ernstfall geklärt sein muss

• Wer bewertet das Risiko? Die Sicherheitsfunktion muss technische Erkenntnisse mit dem Bedrohungskontext verbinden und eine nachvollziehbare Bewertung ermöglichen. Sie sollte nicht allein auf Basis eines allgemeinen Schweregrads entscheiden müssen, wenn geschäftliche Auswirkungen unbekannt sind. Dafür benötigt sie Zugriff auf aktuelle Asset-Informationen und Ansprechpartner aus den betroffenen Bereichen. Bei kritischen Risiken muss klar sein, wann eine Eskalation erforderlich ist. Die Bewertung sollte dokumentiert und bei veränderten Erkenntnissen aktualisiert werden.
• Wer entscheidet über betriebliche Eingriffe? Ein Sicherheitsupdate kann kurzfristig erforderlich sein, gleichzeitig aber Auswirkungen auf einen geschäftskritischen Dienst haben. In solchen Situationen braucht es definierte Entscheidungswege und vorbereitete Notfallverfahren. Die Entscheidung darf nicht an unklaren Zuständigkeiten oder informellen Abstimmungen scheitern. Für besonders dringende Fälle sollten beschleunigte Freigabeprozesse existieren. Diese müssen im Vorfeld festgelegt und regelmäßig überprüft werden.
• Wer setzt die Maßnahme um? Jede relevante Schwachstelle benötigt einen klar benannten Verantwortlichen für die technische Umsetzung. Dazu gehören ein realistischer Termin, die notwendigen Ressourcen und ein dokumentierter Status. Wenn ein externer Dienstleister die Aufgabe übernimmt, müssen Zuständigkeiten und Eskalationswege vertraglich oder organisatorisch abgesichert sein. Die Verantwortung darf nicht einfach in einer E-Mail an einen Dienstleister verschwinden. Auch bei ausgelagertem Betrieb muss das Unternehmen nachvollziehen können, ob die Maßnahme tatsächlich umgesetzt wurde.
• Wer bestätigt die Wirksamkeit? Nach der Umsetzung muss nachvollziehbar geprüft werden, ob die Schwachstelle behoben oder das Risiko ausreichend reduziert wurde. Diese Prüfung kann durch erneute Scans, Versionskontrollen oder andere geeignete technische Nachweise erfolgen. Bei besonders kritischen Fällen sollte die Verifikation nicht allein auf einer unverbindlichen Statusmeldung beruhen. Abweichungen müssen dokumentiert und erneut bearbeitet werden. Der Vorgang ist erst abgeschlossen, wenn die vereinbarten Kriterien erfüllt sind.

Diese Rollenverteilung verbindet technische Arbeit mit organisatorischer Verantwortung. Sie verhindert, dass eine Sicherheitsmeldung zwar formal bearbeitet wird, aber ohne nachweisbare Wirkung bleibt.

Asset Management als Bestandteil der IT-Governance

Asset Management sollte nicht isoliert in der IT-Abteilung betrachtet werden. Es berührt Beschaffung, Lizenzmanagement, Architektur, Informationssicherheit, Datenschutz, Betrieb und Geschäftsprozessverantwortung. Deshalb ist es sinnvoll, gemeinsame Daten und abgestimmte Prozesse aufzubauen, statt für jede Funktion eine voneinander unabhängige Bestandsverwaltung zu betreiben.

Das bedeutet nicht, dass jedes Unternehmen zwingend eine einzige zentrale Datenbank benötigt. Entscheidend ist vielmehr, dass die relevanten Informationen konsistent miteinander verknüpft werden können und klar geregelt ist, welche Quelle für welche Information maßgeblich ist. Ein System kann beispielsweise für technische Versionsdaten zuständig sein, während eine andere Quelle die fachliche Verantwortung oder den Vertragsstatus liefert.

Die Herausforderung liegt darin, Verantwortlichkeiten und Aktualisierungsprozesse eindeutig festzulegen. Wenn mehrere Systeme dieselben Informationen führen, muss klar sein, wie Abweichungen erkannt und korrigiert werden. Ohne solche Regeln wird auch eine technisch moderne Plattform schnell zu einer Sammlung widersprüchlicher Daten.

Der Lebenszyklus eines Assets muss vollständig abgebildet werden

Ein wirksames Asset Management beginnt idealerweise bereits bei der Planung oder Beschaffung einer neuen Anwendung. Schon zu diesem Zeitpunkt sollten Verantwortlichkeiten, Sicherheitsanforderungen, Datenverarbeitung und Betriebsmodell berücksichtigt werden.

Bei der Inbetriebnahme werden die notwendigen Informationen vervollständigt. Während des Betriebs werden Änderungen an Softwareversionen, Konfigurationen, Zuständigkeiten und Abhängigkeiten nachvollziehbar erfasst. Auch größere Architekturänderungen müssen in den relevanten Bestandsdaten sichtbar werden. Bei der Stilllegung wiederum ist sicherzustellen, dass das System tatsächlich außer Betrieb genommen, nicht mehr benötigt und gegebenenfalls ordnungsgemäß bereinigt wurde.

Gerade der letzte Punkt wird häufig unterschätzt. Eine Anwendung kann offiziell als stillgelegt gelten und trotzdem über einen vergessenen Server, einen alten DNS-Eintrag oder einen weiterhin gültigen Zugang erreichbar sein. Ein sauberer Lebenszyklusprozess muss deshalb nicht nur den administrativen Status ändern, sondern die technische Stilllegung verifizieren.

Das NCSC hebt hervor, dass Assets während ihres gesamten Lebenszyklus verwaltet werden sollten. Dazu gehören die laufende Aktualisierung des Inventars, die Berücksichtigung von Abhängigkeiten und die Zuordnung von Verantwortlichkeiten.

Wie Unternehmen ein belastbares Asset Management aufbauen

Ein Unternehmen muss nicht sofort sämtliche Systeme bis ins letzte technische Detail dokumentieren. Ein pragmatischer Einstieg beginnt mit einer Bestandsaufnahme, der Identifikation kritischer Geschäftsprozesse und einer schrittweisen Verbesserung der Datenqualität.

Entscheidend ist, dass Asset Management nicht als einmaliges Projekt behandelt wird. Die IT-Landschaft verändert sich laufend, und die Prozesse müssen diese Veränderungen zuverlässig erfassen. Ein Inventar, das nach seiner Einführung nicht gepflegt wird, verliert mit der Zeit seinen Nutzen.

Ein strukturierter Aufbau kann in sechs Schritten erfolgen.

Schritt 1: Den tatsächlichen Umfang der IT-Landschaft bestimmen

Zunächst muss geklärt werden, welche Kategorien von Assets erfasst werden sollen. Dazu gehören je nach Unternehmen Arbeitsplatzgeräte, Server, Netzwerkkomponenten, virtuelle Systeme, Cloud-Ressourcen, SaaS-Anwendungen, Datenbanken, Softwarebibliotheken und externe Dienste.

Dabei sollte nicht nur die zentrale IT betrachtet werden. Fachbereiche, Entwicklungsabteilungen und externe Dienstleister können weitere relevante Ressourcen betreiben. Eine erste Bestandsaufnahme sollte deshalb unterschiedliche Datenquellen einbeziehen, etwa Netzwerk- und Cloud-Discovery, Endpoint-Management, Beschaffung, Softwareverteilung und bestehende Dokumentationen.

Anschließend werden Lücken sichtbar gemacht. Systeme, die keiner Verantwortung zugeordnet werden können, sollten ausdrücklich als ungeklärt markiert werden. Dadurch entsteht eine priorisierbare Liste von Aufgaben, statt fehlende Informationen unbemerkt zu akzeptieren.

Schritt 2: Kritische Assets priorisieren

Eine vollständige Inventarisierung kann je nach Größe und Komplexität der IT-Landschaft erhebliche Zeit beanspruchen. Deshalb empfiehlt es sich, mit den Systemen zu beginnen, deren Ausfall oder Kompromittierung besonders schwerwiegende Folgen hätte.

Dazu gehören beispielsweise öffentlich erreichbare Anwendungen, Identitätsdienste, zentrale Datenbanken, geschäftskritische Plattformen und Systeme mit besonders schützenswerten Informationen. Welche Assets als kritisch gelten, muss anhand der konkreten Geschäftsprozesse und Risiken festgelegt werden.

Diese Priorisierung ist kein Ersatz für ein vollständiges Inventar. Sie ermöglicht aber, die verfügbaren Ressourcen zunächst auf die Bereiche zu konzentrieren, in denen fehlende Transparenz besonders problematisch wäre.

Schritt 3: Datenquellen automatisiert zusammenführen

Manuelle Tabellen können für einen Einstieg sinnvoll sein, stoßen bei dynamischen IT-Umgebungen jedoch schnell an Grenzen. Automatisierte Discovery-Verfahren helfen dabei, neue Geräte, Anwendungen und Ressourcen zu erkennen und Änderungen zeitnah zu erfassen.

Dabei ist die Qualität der Zuordnung entscheidend. Mehrere Werkzeuge können dasselbe Asset mit unterschiedlichen Kennungen erfassen. Ohne geeignete Abgleichsmechanismen entstehen Dubletten oder widersprüchliche Einträge.

Deshalb sollten Unternehmen definieren, welche Datenquellen für bestimmte Informationen maßgeblich sind und wie Konflikte aufgelöst werden. Automatisierung reduziert den manuellen Aufwand, ersetzt aber nicht die fachliche Verantwortung für die Datenqualität.

Schritt 4: Verantwortlichkeiten verbindlich festlegen

Für kritische Assets muss klar sein, wer für den technischen Betrieb und wer für den jeweiligen Geschäftsprozess verantwortlich ist. Wo diese Rollen bei unterschiedlichen Personen oder Organisationen liegen, müssen die Schnittstellen ausdrücklich definiert werden.

Die Zuordnung sollte nicht ausschließlich in einer schwer auffindbaren Dokumentation stehen. Sie muss im operativen Prozess verfügbar sein, damit Sicherheitsmeldungen schnell an die zuständigen Stellen gelangen.

Unternehmen sollten außerdem regeln, wie Verantwortlichkeiten bei Personalwechseln, organisatorischen Änderungen und Dienstleisterwechseln aktualisiert werden. Eine verwaiste Anwendung darf nicht erst bei der nächsten Sicherheitslücke auffallen.

Schritt 5: Asset Management mit Schwachstellenmanagement verbinden

Der größte praktische Nutzen entsteht, wenn das Inventar direkt in die Sicherheitsprozesse eingebunden wird. Eine neu veröffentlichte Schwachstelle sollte möglichst automatisiert mit den bekannten Softwareständen und Abhängigkeiten abgeglichen werden können.

Die Ergebnisse müssen anschließend um Informationen zur Erreichbarkeit, Kritikalität und möglichen Ausnutzung ergänzt werden. Daraus ergibt sich eine priorisierte Liste von Maßnahmen, die den jeweiligen Verantwortlichen zugewiesen werden kann.

Ebenso wichtig ist der Rückweg: Nach der Behebung müssen die Ergebnisse wieder in den Prozess einfließen. Erst dadurch lässt sich erkennen, ob die Schwachstelle tatsächlich beseitigt wurde und ob weitere Systeme betroffen sein könnten.

Schritt 6: Datenqualität und Prozesse regelmäßig überprüfen

Ein belastbares Asset Management benötigt messbare Qualitätskriterien. Dazu gehört beispielsweise, wie viele kritische Assets vollständig dokumentiert sind, wie viele einen eindeutig benannten Verantwortlichen besitzen und wie schnell neue Ressourcen in das Inventar aufgenommen werden.

Auch ungeklärte Systeme, veraltete Softwarestände und nicht mehr unterstützte Produkte sollten sichtbar gemacht werden. Die Ergebnisse müssen in regelmäßigen Abständen ausgewertet werden, damit sich Verbesserungen und neue Risiken erkennen lassen.

Dabei ist wichtig, Kennzahlen nicht als Selbstzweck zu behandeln. Ein Unternehmen sollte nicht allein darauf hinarbeiten, dass möglichst viele Datensätze ausgefüllt sind. Entscheidend ist, ob die Informationen in der Praxis helfen, Risiken schneller zu erkennen und wirksame Maßnahmen umzusetzen.

Welche Kennzahlen wirklich helfen

Viele IT-Organisationen verfügen über umfangreiche Dashboards. Trotzdem lässt sich aus einer großen Zahl von Kennzahlen nicht automatisch ableiten, ob das Asset Management tatsächlich funktioniert.

Sinnvoll sind Kennzahlen, die Informationsqualität, Reaktionsfähigkeit und tatsächliche Risikoreduktion sichtbar machen. Sie sollten außerdem eine klare Handlungskonsequenz besitzen. Wenn ein Wert schlechter wird, muss nachvollziehbar sein, wer darauf reagiert und welche Maßnahme daraus folgt.

Die folgenden Kennzahlen bieten einen möglichen Einstieg. Die konkreten Zielwerte müssen an die Größe, Kritikalität und Risikosituation des Unternehmens angepasst werden.

Besonders aufschlussreich ist die Zeit bis zur Betroffenheitsanalyse. Wenn ein Unternehmen mehrere Tage benötigt, um festzustellen, welche Systeme von einer kritischen Sicherheitslücke betroffen sind, liegt möglicherweise ein strukturelles Problem vor. Eine schnelle technische Behebung hilft dann nur begrenzt, weil bereits die Ermittlung der relevanten Systeme zu lange dauert.

Gleichzeitig sollten Unternehmen die Kennzahlen nicht isoliert betrachten. Eine niedrige Zahl offener Schwachstellen kann beispielsweise dadurch entstehen, dass Systeme unzureichend gescannt werden. Erst in Verbindung mit Inventarabdeckung, Scanqualität und Verifikation ergibt sich ein aussagekräftigeres Bild.

Asset Management ist auch eine wirtschaftliche Entscheidung

Asset Management wird manchmal als administrative Zusatzaufgabe betrachtet, die Zeit kostet und keinen unmittelbaren Geschäftswert erzeugt. Diese Sichtweise greift zu kurz.

Ein vollständiger Überblick über die IT-Landschaft hilft nicht nur bei der Abwehr von Angriffen. Er unterstützt auch die Lizenzverwaltung, die Planung von Ersatzbeschaffungen, die Identifikation veralteter Systeme, die Vorbereitung von Migrationen und die Bewertung externer Dienstleister.

Wenn Unternehmen nicht wissen, welche Anwendungen tatsächlich genutzt werden, können sie unnötige Lizenzen bezahlen oder redundante Systeme weiterbetreiben. Wenn sie den Supportstatus ihrer Produkte nicht kennen, werden notwendige Modernisierungen möglicherweise zu spät eingeplant. Und wenn technische Abhängigkeiten unklar sind, können selbst überschaubare Änderungen unerwartet hohe Kosten verursachen.

Der wirtschaftliche Nutzen liegt deshalb nicht allein in vermiedenen Sicherheitsvorfällen. Er entsteht auch durch bessere Planung, weniger Suchaufwand, nachvollziehbare Verantwortlichkeiten und fundiertere Investitionsentscheidungen.

Ein Beispiel aus der Praxis

Ein Unternehmen möchte seine interne Anwendungslandschaft modernisieren. Die Projektverantwortlichen rechnen mit einer überschaubaren Migration, weil nur wenige Anwendungen offiziell dokumentiert sind.

Bei einer systematischen Bestandsaufnahme zeigt sich jedoch, dass mehrere Fachbereiche zusätzliche Anwendungen betreiben. Einige davon greifen auf dieselben Datenbanken zu, andere nutzen ältere Schnittstellen oder werden von externen Dienstleistern betreut. Dadurch verändert sich nicht nur der Umfang des Migrationsprojekts. Auch die Sicherheitsbewertung, die Ressourcenplanung und die Reihenfolge der Umstellung müssen angepasst werden.

Das Asset Management hat in diesem Fall nicht einfach eine Liste vervollständigt. Es hat eine bessere Entscheidungsgrundlage geschaffen und möglicherweise verhindert, dass das Projekt mit unrealistischen Annahmen gestartet wird.

Genau darin liegt seine strategische Bedeutung: Transparenz über die IT-Landschaft verbessert nicht nur die Sicherheit, sondern auch die Steuerungsfähigkeit des Unternehmens.

Warum Geschäftsführung und IT-Leitung das Thema gemeinsam verantworten müssen

Die Verantwortung für Asset Management darf nicht allein bei einzelnen Administratoren liegen. Die IT benötigt zwar die technischen Werkzeuge und Prozesse, um Systeme zu erkennen und Bestandsdaten aktuell zu halten. Die vollständige Sicht auf die IT-Landschaft entsteht jedoch nur, wenn auch Beschaffung, Fachbereiche, Entwicklung und externe Dienstleister eingebunden sind.

Die Geschäftsführung muss dafür sorgen, dass Zuständigkeiten, Ressourcen und verbindliche Regeln vorhanden sind. Die IT-Leitung muss die operative Umsetzung organisieren und sicherstellen, dass technische Informationen in den Sicherheits- und Betriebsprozessen genutzt werden. Die Informationssicherheit wiederum benötigt ausreichende Transparenz, um Risiken bewerten und geeignete Maßnahmen anstoßen zu können.

Besonders wichtig ist die Verbindung zwischen geschäftlicher Kritikalität und technischen Entscheidungen. Eine Anwendung kann aus technischer Sicht unscheinbar wirken, aber einen zentralen Geschäftsprozess ermöglichen. Umgekehrt kann eine technisch komplexe Umgebung für den Geschäftsbetrieb nur eine untergeordnete Rolle spielen. Ohne die Zusammenarbeit zwischen Fachbereich und IT lassen sich diese Unterschiede nicht zuverlässig beurteilen.

Asset Management sollte deshalb als gemeinsame Managementaufgabe verstanden werden. Die IT stellt die technische Transparenz her, die Fachbereiche liefern den geschäftlichen Kontext und die Unternehmensleitung schafft die Voraussetzungen für verbindliche Entscheidungen.

Wer von seiner IT Sicherheit, Verfügbarkeit und Verlässlichkeit erwartet, muss auch sicherstellen, dass die Organisation ihre IT kennt und steuern kann.

Fazit: Die erste Verteidigungslinie ist der Überblick über die eigene IT

Wenn Unternehmen Sicherheitslücken nicht rechtzeitig erkennen, liegt das Problem nicht zwangsläufig an fehlenden Sicherheitsprodukten. Häufig fehlt vielmehr eine verlässliche Grundlage, um technische Warnungen mit der tatsächlichen IT-Landschaft abzugleichen.

Ein unvollständiges Inventar erschwert die Identifikation betroffener Systeme. Fehlende Verantwortlichkeiten verzögern Entscheidungen. Unbekannte Abhängigkeiten erschweren die Risikobewertung. Und ohne Verifikation bleibt unklar, ob eine Maßnahme tatsächlich wirksam war.

Asset Management ist deshalb kein bürokratischer Selbstzweck. Es ist ein grundlegender Bestandteil eines wirksamen Schwachstellenmanagements und eine Voraussetzung für belastbare IT-Governance.

Unternehmen sollten nicht erst bei der nächsten kritischen Sicherheitsmeldung damit beginnen, ihre Systeme zu suchen. Sie benötigen einen kontinuierlichen Prozess, der relevante Assets identifiziert, ihre Bedeutung bewertet, Verantwortlichkeiten festlegt und Veränderungen nachvollziehbar dokumentiert.

Die gute Nachricht: Dafür muss nicht sofort die gesamte IT-Landschaft perfekt dokumentiert sein. Ein sinnvoller Einstieg beginnt mit den kritischsten Systemen, klaren Zuständigkeiten und einer systematischen Verbesserung der Datenqualität. Anschließend lassen sich Erkennung, Risikobewertung und Maßnahmenumsetzung schrittweise miteinander verbinden.

Die entscheidende Frage ist nicht, ob ein Unternehmen eine Inventarliste besitzt. Sie lautet, ob es im Ernstfall schnell und zuverlässig beantworten kann, welche Systeme betroffen sind, welche Geschäftsprozesse gefährdet werden und wer jetzt handeln muss. Denn eine Sicherheitslücke lässt sich möglicherweise mit einem Update schließen. Die Unsicherheit über die eigene IT-Landschaft lässt sich dagegen nur durch konsequentes Asset Management beseitigen.

Wie schnell könnte Dein Unternehmen heute belastbar feststellen, welche Systeme von einer neu bekannt gewordenen kritischen Sicherheitslücke betroffen sind – und wer für die Behebung verantwortlich ist?

Ist das bei Euch ein automatisierter Prozess oder beginnt im Ernstfall zunächst die Suche nach den richtigen Informationen und Ansprechpartnern, sofern es die Ansprechpartner überhaupt noch gibt?