IT Asset Management (ITAM) und Cybersicherheit: Alles inventarisieren, alles schützen

„You can’t protect what you don’t know you have.” - dieses Prinzip ist das Fundament jeder Sicherheitsstrategie. IT Asset Management (ITAM) sorgt dafür, dass Unternehmen einen vollständigen, aktuellen Überblick über alle IT-Assets behalten: Hardware, Software, Cloud-Ressourcen, Lizenzen und ihre Abhängigkeiten.

Warum ITAM die Basis jeder Sicherheitsstrategie ist

Das ungepatchte-Asset-Problem:

Szenario: Ransomware-Angriff Oktober 2024
  Einstieg: CVE-2024-XXXX in Windows Server 2012 R2
  Frage: "Haben wir noch Windows 2012 R2 Systeme?"
  Antwort ohne ITAM: "Wir glauben nicht..."
  Reality: 3 vergessene VMs im Keller-ESXi

Warum passiert das?
  → Organisches IT-Wachstum über Jahre
  → Keine strukturierte Übergabe bei Mitarbeiterwechseln
  → Shadow-IT: Abteilungen kaufen ohne IT-Abteilung
  → Cloud-Sprawl: Teams erstellen EC2-Instanzen, vergessen sie
  → Virtualisierung: VMs werden geklont, umbenannt, vergessen

CIS Control 1 und 2 fordern genau das:
  Control 1: Inventar und Kontrolle von Enterprise-Assets
  Control 2: Inventar und Kontrolle von Software-Assets

ITAM-Lücken = Sicherheitslücken:
  Unbekanntes Asset → kein Patch → bekannte CVE → Angriff

Statistik:
  → 20% der IT-Assets in mittelgroßen Unternehmen sind nicht inventarisiert
    (Freshservice State of IT, 2023)
  → 67% der Ransomware-Angriffe nutzen ungepatchte bekannte CVEs aus
    (IBM X-Force, 2024)

CMDB - Configuration Management Database

CMDB-Konzept (nach ITIL):

Configuration Item (CI):
  → Jedes Asset das verwaltet wird
  → Hat Attribut: Name, Typ, Version, Eigentümer, Standort, Status
  → Typen: Hardware, Software, Service, Dokument, Zertifikat

CMDB-Struktur Beispiel:

CI: web-prod-01
  Typ:        Physical Server
  Model:      Dell PowerEdge R750
  OS:         Ubuntu 22.04 LTS
  IP:         10.0.2.10
  MAC:        00:50:56:AB:CD:EF
  Rack:       Rechenzentrum RZ1, Rack-03, HE 12-14
  Eigentümer: IT Operations
  Applikation: Nginx 1.24, Node.js 20.x, PostgreSQL 15
  Letzter Patch: 2026-02-28
  Nächster Patch: 2026-03-28
  End-of-Life: 2027-06-30 (Hardware)
  Abhängigkeiten: → load-balancer-01, → db-cluster-01

Beziehungen in der CMDB:
  web-prod-01 → verwendet → nginx:1.24 (Software)
  web-prod-01 → connected-to → db-cluster-01 (Server)
  web-prod-01 → hosted-on → esxi-host-02 (wenn VM)
  nginx:1.24  → has-vulnerability → CVE-2023-44487 (HTTP/2 Rapid Reset)

CMDB-Tools:
  Open Source:
    → iTop (CMDB + ITSM, kostenlos)
    → Ralph (ausgezeichnetes Open-Source-ITAM-Tool)
    → NetBox (Netzwerk/Datacenter-fokussiert)
    → Snipe-IT (Asset Tracking, sehr benutzerfreundlich)

  Kommerziell:
    → ServiceNow CMDB (Enterprise-Standard)
    → Freshservice CMDB (SME/Mittelstand)
    → Lansweeper (sehr gut für automatische Discovery)
    → Device42 (CMDB + Discovery + Dependency Mapping)

Automatische Asset-Discovery

Wie man Assets findet die man nicht kennt:

Netzwerk-Scan-basierte Discovery:

Nmap für Basisinventar:
# Alle aktiven Hosts im Netz entdecken
nmap -sn 10.0.0.0/16 -oX discovery.xml

# Betriebssystem und Services erkennen
nmap -O -sV 10.0.0.0/16 -oX inventory.xml

# Nur spezifische Ports (schneller für große Netze)
nmap -p 22,80,443,3389,445 10.0.0.0/16 --open

# Output in CSV für Excel/Import
nmap -p 22,80,443 10.0.0.0/16 -oG - | \
  awk '/Up/{print $2}' > live-hosts.txt

Nessus Essentials (kostenlos bis 16 IPs):
  → Vulnerability-Scan + Asset-Discovery kombiniert
  → Findet OS, Patches, Dienste, Konfigurationsprobleme
  → Export als CSV/XML für CMDB-Import

OpenVAS (kostenlos, unbegrenzt):
  → Vollständiger Vulnerability Scanner
  → Asset-Discovery als Nebenprodukt
  → Regelmäßige Updates der Vulnerability-Datenbank

Agent-basierte Discovery:
  → Lansweeper Agent: installiert auf Endgeräten
  → Sendet regelmäßig vollständige Hardware/Software-Inventur
  → Findet auch Assets hinter NAT / in Remote-Office

Cloud-Asset-Discovery:
  AWS:
    aws ec2 describe-instances --query \
      'Reservations[].Instances[].[InstanceId,State.Name,
       PublicIpAddress,PrivateIpAddress,Tags[?Key==`Name`].Value|[0]]' \
      --output table

  Azure:
    az resource list --output table

  GCP:
    gcloud compute instances list

  Multi-Cloud:
    → Prisma Cloud: alle Clouds in einer Übersicht
    → Wiz: Cloud Asset Inventory + Risikobewertung
    → AWS Security Hub + Azure Security Center kombinieren

Software Asset Management und SBOM

Software Inventory - warum es so wichtig ist:

Software-Inventar Mindestanforderungen:
  → Name und Version jeder installierten Anwendung
  → Lizenz-Informationen (Compliance!)
  → Patch-Status und bekannte CVEs
  → Für wen installiert? (Asset-Verknüpfung)
  → Installationsdatum und letzte Aktualisierung

Automatische Software-Inventarisierung:

Windows (WMI):
wmic product get Name, Version, InstallDate, InstallLocation

# Via PowerShell (alle installierten Programme):
Get-WmiObject -Class Win32_Product | Select Name,Version,Vendor |
  Sort Name | Export-Csv software-inventory.csv

# Besser: Auch aus Registry:
Get-ChildItem HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall |
  Get-ItemProperty | Select DisplayName,DisplayVersion,Publisher |
  Sort DisplayName

Linux (Debian/Ubuntu):
dpkg --list | awk '{print $2, $3}' > software-inventory.txt

# RPM (RHEL/CentOS):
rpm -qa --queryformat '%{NAME} %{VERSION}\n' > software-inventory.txt

SBOM (Software Bill of Materials):

Was ist SBOM?
  → Vollständiges Inventar aller Softwarekomponenten
  → Inkl. aller Bibliotheken und deren Abhängigkeiten
  → Standard-Formate: SPDX (ISO/IEC 5962), CycloneDX
  → Pflicht durch US Executive Order (Mai 2021) für US-Govt-Software
  → In EU durch NIS2 und CRA (Cyber Resilience Act) zunehmend erwartet

SBOM generieren mit Syft:
# Docker-Image scannen:
syft myapp:latest -o spdx-json > sbom-myapp.json

# Source-Code-Repository scannen:
syft dir:./src -o cyclonedx-json > sbom-source.json

# SBOM auf Schwachstellen prüfen mit Grype:
grype sbom:./sbom-myapp.json

# Zeigt an: alle bekannten CVEs in Abhängigkeiten!

Log4Shell-Lesson: "Habe ich log4j im Einsatz?"
  Ohne SBOM: wochenlange manuelle Suche
  Mit SBOM: grep "log4j" sbom-*.json → sofortige Antwort

Hardware-Lifecycle-Management

Hardware-Lifecycle und Sicherheitsrisiken:

End-of-Life (EOL) / End-of-Support (EOS):

  EOL bedeutet: keine Sicherheits-Patches mehr!
  Jede bekannte Schwachstelle bleibt dauerhaft offen.

Kritische EOL-Daten (2026):
  Windows 10:          Oktober 2025 (EOS!) → sofort migrieren!
  Windows Server 2012: Oktober 2023 (EOS!) → sofort migrieren!
  Windows Server 2016: Januar 2027 → Migration planen!
  PHP 8.1:             Dezember 2025 → upgrade!
  CentOS 7:            Juni 2024 (EOS!) → migrieren!
  Python 3.8:          Oktober 2024 (EOS!)

ITAM-Prozess für EOL-Management:
  1. Alle Assets mit OS/Software-Version in CMDB
  2. EOL-Daten automatisch aus vendor-feeds laden
  3. Alert bei < 12 Monate bis EOL
  4. Budget-Planung: Migration/Replacement budgetieren
  5. Ausnahmen dokumentieren + Risiko akzeptieren + kompensieren

Hardware-Replacement-Zyklus:
  Workstations:    4-5 Jahre
  Laptops:         3-4 Jahre
  Server:          5-7 Jahre
  Netzwerk-Switches: 7-10 Jahre (mit Firmware-Support!)
  Firewalls:       3-5 Jahre
  Storage:         5-7 Jahre

Warum kurze Zyklen? Hardware-Sicherheitslücken:
  → Spectre/Meltdown: Hardware-Firmware-Update nötig
  → Log4Shell auf embedded Devices: selten patchbar
  → Ältere Hardware: kein TPM 2.0 → kein Windows 11, kein Bitlocker
  → IoT-Geräte: oft keine Security-Updates nach 2-3 Jahren

ITAM für Compliance

ITAM-Anforderungen in Normen und Gesetzen:

ISO 27001:2022:
  A.5.9: Inventar von Informationen und anderen Assets
    → "vollständiges und aktuelles Inventar"
    → Klassifizierung nach Schutzbedarf

  A.5.10: Akzeptable Verwendung von Informationen und anderen Assets
    → Nutzungsregeln für klassifizierte Assets

  A.5.11: Rückgabe von Assets
    → Austrittsverfahren: alle Assets zurück!

NIS2 Art. 21:
  → "Vermögenswerte und Risiken müssen bekannt sein"
  → Vollständiges Asset-Inventar als Grundlage

BSI IT-Grundschutz:
  ORP.1: Organisation
  → Asset-Inventar explizit gefordert

Audit-Dokumentation:
  Was Auditoren sehen wollen:
  □ Vollständiges Asset-Inventar (< 6 Monate alt)
  □ Asset-Owner für alle kritischen Assets
  □ Klassifizierung nach Schutzbedarf
  □ EOL/EOS-Management dokumentiert
  □ Prozess für neue Assets (Onboarding) und alte (Decommission)
  □ Regelmäßige Überprüfung (Frequenz dokumentiert)

Quick-Win-Checkliste:
  □ Inventar-Tabelle erstellen (Asset, Owner, OS, Version, IP)
  □ Nmap-Scan gegen eigenes Netz: was findet man was man nicht kennt?
  □ Windows WSUS / SCCM: wie viele Geräte mit fehlendem Patch?
  □ Alle Geräte die seit > 90 Tagen kein Update hatten identifizieren
  □ EOL-Check: welche OS/Software läuft out-of-support?