Blue Teaming

Blue Teaming beschreibt die defensive Seite der Cybersicherheit: Das Blue Team ist dafür verantwortlich, Angriffe zu erkennen, abzuwehren, zu analysieren und sich kontinuierlich gegen neue Bedrohungen zu wappnen.

Aufgaben des Blue Teams

  • Überwachung von Systemen und Netzwerken

  • Erkennung und Analyse von Angriffen (z. B. via SIEM, EDR, IDS)

  • Incident Response: Reaktion auf Sicherheitsvorfälle

  • Forensik und Ursachenanalyse

  • Härtung von Systemen, Netzwerken und Anwendungen

  • Awareness-Trainings und Sicherheitsrichtlinien

Werkzeuge & Methoden

  • Security Information and Event Management (SIEM)

  • Endpoint Detection and Response (EDR)

  • Netzwerk-Monitoring / Traffic-Analyse

  • Vulnerability Management

  • Threat Intelligence Plattformen

Zielsetzung

Das Blue Team schützt die Organisation vor, während und nach einem Angriff – durch aktive Abwehrmaßnahmen, Monitoring, Schulungen und laufende Optimierung.

Blue Teaming ist der operative Kern der IT-Sicherheit: Es hält Systeme stabil, erkennt Angriffe frühzeitig und reagiert effektiv – ein essenzieller Bestandteil der Cyberresilienz.

Red Teaming

Red Teaming ist eine offensive Sicherheitsmethode, bei der ein Team aus ethischen Hackern realistische Cyberangriffe simuliert, um Schwachstellen in der IT-Infrastruktur, in Anwendungen und im Verhalten von Mitarbeitenden aufzudecken.

Zielsetzung

Das Red Team agiert wie ein echter Angreifer – kreativ, zielgerichtet und unerwartet. Im Gegensatz zu standardisierten Penetrationstests liegt der Fokus nicht nur auf technischen Lücken, sondern auch auf Prozessen, physischen Zugriffen und menschlichem Verhalten (z. B. durch Social Engineering).

Typische Angriffswege

  • Phishing-E-Mails zur Initialkompromittierung

  • Exploits von Schwachstellen in Software oder Netzwerken

  • Seitliche Bewegung im internen Netz (Lateral Movement)

  • Umgehung von Sicherheitsmechanismen

  • Datendiebstahl oder Simulation eines Ransomware-Angriffs

Vorteile

  • Realitätsnahe Überprüfung der Abwehrmechanismen

  • Aufdeckung versteckter Schwachstellen, die automatisierte Scans nicht finden

  • Stärkung des Sicherheitsbewusstseins im Unternehmen

  • Vorbereitung auf echte Angriffsszenarien

Red Teaming zeigt Unternehmen, wo sie wirklich verwundbar sind – über technische Grenzen hinaus. Es ist ein unverzichtbares Element jeder ganzheitlichen Sicherheitsstrategie.

LOTL „Living off the Land“

LOTL steht für „Living off the Land“ und beschreibt eine Technik in der IT-Sicherheit, bei der Angreifer legitime, bereits auf dem System vorhandene Werkzeuge und Funktionen verwenden, um ihre Ziele zu erreichen – z. B. für Angriffe, Ausbreitung, Datenexfiltration oder Persistenz.

Anstatt eigene Malware einzuschleusen, nutzen LOTL-Angriffe vorhandene Tools wie PowerShell, WMI oder legitime Admin-Tools – was sie besonders schwer zu erkennen macht.

Was bedeutet Living off the Land genau?

LOTL-Angriffe zielen darauf ab, sich unauffällig innerhalb eines Systems oder Netzwerks zu bewegen, indem ausschließlich vertrauenswürdige (systemeigene oder bereits installierte) Tools verwendet werden. Dadurch umgehen sie häufig klassische Sicherheitsmechanismen wie Signatur-basierte Virenscanner oder einfache Whitelisting-Strategien.

Typische Beispiele für LOTL-Tools

Tool / Technik Beschreibung / Zweck im Angriff
PowerShell Skriptausführung, Datenexfiltration, Remote-Steuerung
WMI (Windows Management Instrumentation) Systemabfragen, Prozessstart, persistente Backdoors
PsExec Ausführung von Befehlen auf Remote-Systemen
CertUtil Download und Dekodierung von Malware
RDP / SMB / FTP Seitliche Bewegung im Netzwerk
MSHTA / rundll32.exe Code-Ausführung über legitime Systemprozesse

Ziele und Vorteile für Angreifer

  • Unentdeckt bleiben: Weniger auffällig, da keine unbekannten Tools genutzt werden

  • Umgehung von Schutzsystemen: Antivirus, EDR und Firewalls können umgangen werden

  • Schneller Zugriff: Viele Tools sind auf Zielsystemen bereits verfügbar

  • Persistenz: Oft schwer zu entfernen, da keine externen Dateien im Spiel sind

Abwehrstrategien gegen LOTL

  • Verhaltensbasierte Erkennung (z. B. EDR/XDR) statt nur Signaturen

  • Harte PowerShell-Einschränkungen (z. B. Constrained Language Mode)

  • Anwendungskontrolle (Application Whitelisting)

  • Protokollierung und Anomalieerkennung

  • Least Privilege-Prinzip: Minimale Rechtevergabe für Nutzer und Dienste

LOTL („Living off the Land“) ist eine raffinierte Angriffsstrategie, bei der Angreifer auf vorhandene, vertrauenswürdige Tools zurückgreifen, um unerkannt zu operieren. Für Unternehmen bedeutet das: klassische Schutzmaßnahmen reichen oft nicht aus – moderne, verhaltensbasierte Sicherheitslösungen und präventive Architekturentscheidungen sind entscheidend.

HCI-Stack

HCI-Stack (Hyper-Converged Infrastructure Stack)

Ein HCI-Stack ist eine integrierte Lösung, die Rechenleistung (Compute), Speicher (Storage) und Netzwerkfunktionen in einer einheitlichen, softwaregesteuerten Plattform vereint. Die Abkürzung HCI steht für Hyper-Converged Infrastructure.

Was ist ein HCI-Stack?

Ein HCI-Stack kombiniert traditionelle Infrastrukturkomponenten in einer vollständig virtualisierten Umgebung, bei der die gesamte Steuerung über eine zentrale Softwareplattform erfolgt – statt über separate dedizierte Hardwarelösungen für Server, Speicher und Netzwerk.

Typische Bestandteile eines HCI-Stacks:

  • Hypervisor (z. B. Microsoft Hyper-V, VMware ESXi)

  • Software-defined Storage (SDS) (z. B. Storage Spaces Direct, vSAN)

  • Software-defined Networking (SDN)

  • Verwaltungsoberfläche / Orchestrierung (z. B. System Center, Windows Admin Center, vCenter)

  • Optional: Backup-, Monitoring- und Security-Lösungen

Vorteile eines HCI-Stacks

  • Vereinfachte IT-Infrastruktur: Alles in einer Plattform, zentral steuerbar

  • Hohe Skalierbarkeit: Einfaches Hinzufügen weiterer Knoten („scale-out“)

  • Automatisierung & Effizienz: Weniger manuelle Eingriffe, mehr Konsistenz

  • Geringere Betriebskosten: Weniger dedizierte Hardware erforderlich

  • Optimiert für Virtualisierung & Containerisierung

Typische Einsatzbereiche

  • Private Clouds & Edge-Umgebungen

  • Remote- und Zweigstellen-Infrastruktur

  • VDI (Virtual Desktop Infrastructure)

  • Hochverfügbare und skalierbare Workloads

  • Modernisierung von Rechenzentren

Beispiele für HCI-Plattformen

  • Microsoft Azure Stack HCI

  • VMware vSAN Ready Nodes

  • Nutanix

  • Dell VxRail

  • HPE SimpliVity

Ein HCI-Stack bietet eine moderne, konsolidierte IT-Infrastruktur, die Leistung, Einfachheit und Skalierbarkeit vereint. Er eignet sich besonders für Unternehmen, die ihre Rechenzentren effizienter gestalten, automatisieren und für Cloud-Technologien vorbereiten möchten.

HCI-Stack vs. klassische Infrastruktur

Kriterium HCI-Stack Klassische Infrastruktur
Architektur Integriert (Compute, Storage, Netzwerk in einem Stack) Getrennte Systeme für Server, Storage und Netzwerk
Verwaltung Zentralisiert über eine einheitliche Oberfläche Mehrere Tools, manuelle Koordination erforderlich
Skalierung Horizontal durch Hinzufügen weiterer Nodes Oft vertikal (Upgrades bestehender Komponenten)
Initiale Komplexität Einfacher Einstieg durch vorkonfigurierte Lösungen Höhere Planungs- und Integrationsaufwände
Investitionskosten Geringer Einstieg, skalierbar nach Bedarf Höhere Anfangsinvestitionen für dedizierte Hardware
Betriebskosten Niedriger durch weniger Hardware und zentralisiertes Management Höher durch komplexe Wartung und separate Systeme
Verfügbarkeit & Redundanz Eingebaut (z. B. automatische Replikation, Failover) Muss individuell geplant und implementiert werden
Typische Nutzung Virtualisierung, VDI, Edge, Private Cloud Klassische Rechenzentren, Legacy-Systeme
Cloud-Integration Native Anbindung an Hybrid-/Public-Clouds möglich Meist über zusätzliche Gateways oder Lösungen

Kubernetes

Kubernetes

Kubernetes (oft abgekürzt als K8s) ist eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Es wurde ursprünglich von Google entwickelt und wird heute von der Cloud Native Computing Foundation (CNCF) verwaltet.

Was ist Kubernetes?

Kubernetes ist ein sogenannter Container-Orchestrator. Es übernimmt die Aufgabe, Anwendungen, die in Containern (z. B. mit Docker) verpackt sind, effizient in einer verteilten Infrastruktur auszuführen. Dabei sorgt Kubernetes automatisch für:

  • Lastverteilung

  • Ausfallsicherheit

  • Skalierung nach Bedarf

  • Ressourcenzuweisung

  • Rollouts und Rollbacks von Updates

Zentrale Komponenten von Kubernetes

  • Pods: Die kleinste deploybare Einheit; enthält einen oder mehrere Container

  • Nodes: Die Maschinen (virtuell oder physisch), auf denen Kubernetes Workloads ausführt

  • Cluster: Eine Gruppe von Nodes, die gemeinsam verwaltet werden

  • Control Plane: Steuert den gesamten Cluster und trifft Entscheidungen über Scheduling, Skalierung etc.

  • Services & Ingress: Regeln den Zugriff auf Anwendungen innerhalb und außerhalb des Clusters

Einsatzbereiche von Kubernetes

  • Microservices-Architekturen

  • DevOps-Umgebungen

  • Cloud-native Anwendungen

  • Hybride und Multi-Cloud-Szenarien

  • Automatisierung komplexer Anwendungslandschaften

Vorteile von Kubernetes

  • Hohe Skalierbarkeit: Anwendungen lassen sich horizontal nach Bedarf skalieren

  • Plattformunabhängigkeit: Läuft auf nahezu jeder Infrastruktur (lokal, in der Cloud oder hybrid)

  • Automatisierung: Minimiert manuelle Eingriffe und reduziert Betriebskosten

  • Hohe Verfügbarkeit: Integrierte Mechanismen zur Fehlererkennung und -behebung

  • Modularität: Integration mit vielen anderen Tools aus dem Cloud Native-Ökosystem

Kubernetes ist heute der De-facto-Standard für Container-Orchestrierung. Es bietet eine leistungsstarke und flexible Plattform, um moderne Anwendungen zuverlässig, skalierbar und automatisiert zu betreiben – egal ob im eigenen Rechenzentrum, in der Public Cloud oder in einer hybriden Umgebung.

Kubernetes vs. klassische virtuelle Maschinen (VMs)

Kriterium Kubernetes (Container-Orchestrierung) Klassische VMs (z. B. mit Hyper-V, VMware)
Architektur Containerbasiert (leichtgewichtig, gemeinsames OS) Vollständige Betriebssysteme pro VM
Ressourcennutzung Sehr effizient (geringer Overhead) Weniger effizient (höherer Ressourcenverbrauch)
Startzeit Sekunden Minuten
Skalierung Automatisiert, dynamisch (Horizontal Pod Autoscaling) Manuell oder mit zusätzlichen Tools
Deployment YAML-Dateien, deklarativ Über Images, Snapshots oder Templates
Portabilität Hoch (plattform- und cloudunabhängig) Eingeschränkt (abhängig vom Hypervisor/Host)
Fehlertoleranz & Self-Healing Eingebaut (z. B. Neustart von Pods bei Fehlern) Manuell oder mit Zusatzsoftware
Netzwerkmodell Integriert (Service Discovery, Ingress, Load Balancing) Extern konfiguriert (z. B. mit Load Balancern)
Updates & Rollbacks Automatisiert und versionierbar Oft manuell oder mit Snapshot-Wiederherstellung
Verwaltungsaufwand Höherer initialer Aufwand, später automatisierbar Einfacher Einstieg, später komplex in Skalierung und Pflege
Typische Einsatzbereiche Cloud-native Apps, Microservices, CI/CD, Skalierung Legacy-Anwendungen, monolithische Systeme

Arc Local

Arc Local (Microsoft Azure Arc Local)

Arc Local ist ein Bestandteil von Microsoft Azure Arc, einer Plattform, mit der sich Ressourcen außerhalb von Azure – wie Server, Kubernetes-Cluster und Datenbanken – zentral über das Azure-Portal verwalten lassen. Im speziellen Fokus von Arc Local steht die Verwaltung von lokalen und Edge-Ressourcen, die nicht dauerhaft mit der Cloud verbunden sind.

Was ist Arc Local?

Arc Local ermöglicht es Unternehmen, Azure-Managementfunktionen wie Richtlinien, Überwachung, Sicherheitskonfigurationen und Inventarisierung auch auf lokalen Geräten oder in Edge-Umgebungen bereitzustellen – ohne dass eine dauerhafte Internetverbindung erforderlich ist.

Das Konzept ist ideal für Szenarien, in denen Cloudverbindung nur temporär oder eingeschränkt möglich ist – etwa in Produktionsstätten, abgelegenen Standorten oder sicherheitskritischen Netzwerken.

Funktionen von Arc Local

  • Verwaltung von Ressourcen ohne ständige Cloudbindung

  • Temporäre Synchronisation mit Azure, sobald eine Verbindung verfügbar ist

  • Bereitstellung von Richtlinien, Updates und Überwachung lokal

  • Unterstützung für hybride und Edge-Szenarien

  • Azure-ähnliches Management-Erlebnis für On-Premises-Umgebungen

Typische Einsatzbereiche

  • Edge Computing, z. B. in Fertigung, Logistik oder Einzelhandel

  • Isolierte Rechenzentren mit eingeschränkter oder keiner Internetverbindung

  • Sicherheitskritische IT-Umgebungen, z. B. im Finanz- oder Gesundheitswesen

  • Organisationen mit hybrider IT-Strategie

Vorteile von Arc Local

  • Zentralisierte Verwaltung aller Ressourcen – ob Cloud, lokal oder Edge

  • Einheitliche Sicherheitsrichtlinien über alle Umgebungen hinweg

  • Reduzierter Verwaltungsaufwand, da alle Systeme in Azure sichtbar und steuerbar sind

  • Cloud-Management ohne Cloud-Abhängigkeit

Arc Local erweitert die Azure-Verwaltung auf lokale und Edge-Ressourcen – auch in Umgebungen mit eingeschränkter oder temporärer Cloudverbindung. Es ist eine Schlüsselkomponente für Unternehmen, die eine moderne, hybride IT-Strategie verfolgen und gleichzeitig ihre lokalen Systeme effizient integrieren möchten.

SCVMM

SCVMM (System Center Virtual Machine Manager)

SCVMM steht für System Center Virtual Machine Manager und ist eine zentrale Verwaltungsplattform von Microsoft zur effizienten Verwaltung virtueller Infrastrukturen in Rechenzentren. Es ist Teil der System Center Suite und speziell für den Einsatz in Hyper-V-basierten Virtualisierungsumgebungen konzipiert.

Was ist SCVMM?

SCVMM ist ein Verwaltungswerkzeug, das es IT-Administratoren ermöglicht, virtuelle Maschinen (VMs), Hosts, Netzwerke und Speicherressourcen zentral zu verwalten. Dabei unterstützt SCVMM nicht nur Microsoft Hyper-V, sondern kann auch VMware vSphere und Citrix XenServer in begrenztem Umfang integrieren.

Wichtige Funktionen von SCVMM

  • Zentrale VM-Verwaltung: Erstellung, Bereitstellung und Überwachung von virtuellen Maschinen über eine einheitliche Konsole

  • Fabric Management: Verwaltung der zugrunde liegenden Ressourcen wie Compute, Netzwerk und Storage

  • Service Templates: Automatisierte Bereitstellung komplexer, mehrschichtiger Dienste

  • Integration mit Azure: Möglichkeit zur Verwaltung von hybriden Umgebungen und Verbindung zu Microsoft Azure

  • Software-defined Networking (SDN): Unterstützung für moderne Netzwerkvirtualisierung in Windows Server

Einsatzbereiche

  • Rechenzentren und Enterprise-Umgebungen, die eine Vielzahl von Hyper-V-Hosts und VMs betreiben

  • Private Clouds, bei denen SCVMM als zentrales Verwaltungswerkzeug dient

  • Organisationen, die automatisierte Workflows und Infrastructure as a Service (IaaS)-Modelle realisieren möchten

Vorteile

  • Skalierbarkeit: Verwaltung großer, komplexer Virtualisierungslandschaften

  • Effizienz: Automatisierung von Aufgaben wie VM-Bereitstellung, Patching oder Lastverteilung

  • Konsolidierung: Eine Konsole für die komplette Verwaltung von Compute-, Netzwerk- und Speicherressourcen

  • Kostenkontrolle: Optimierung der Ressourcennutzung durch Monitoring und Reporting

Fazit

System Center Virtual Machine Manager (SCVMM) ist ein leistungsstarkes Tool für die Verwaltung von Virtualisierungsumgebungen auf Enterprise-Niveau. Es bietet umfassende Funktionen zur Steuerung und Optimierung von virtuellen Infrastrukturen und ist ein zentraler Bestandteil moderner, softwaredefinierter Rechenzentren.

Entra ID

Entra ID (mit Entra Connect Sync)

Entra ID (ehemals Azure Active Directory) ist Microsofts cloudbasierter Identitäts- und Zugriffsverwaltungsdienst. Die Ergänzung „mit Entra Connect Sync“ beschreibt die Synchronisierung lokaler Verzeichnisse – typischerweise ein Windows Server Active Directory (AD) – mit Microsofts Cloudlösung.

Was ist Entra ID mit Entra Connect Sync?

„Entra ID mit Entra Connect Sync“ bezeichnet die Kombination aus lokalem Active Directory und der cloudbasierten Identitätsplattform Microsoft Entra ID, verbunden durch das Tool Microsoft Entra Connect Sync. Dieses Tool überträgt Benutzerkonten, Gruppen und andere Verzeichniselemente automatisch aus dem lokalen AD in die Cloud.

Vorteile der Synchronisierung mit Entra Connect Sync

  • Zentrale Identitätsverwaltung: Nutzeridentitäten werden lokal gepflegt und automatisch in der Cloud bereitgestellt.

  • Single Sign-On (SSO): Mitarbeitende erhalten mit einer Anmeldung Zugriff auf lokale und cloudbasierte Anwendungen wie Microsoft 365.

  • Hybride IT-Unterstützung: Ideal für Unternehmen, die Cloud-Dienste einführen und gleichzeitig bestehende On-Premise-Strukturen weiter nutzen möchten.

  • Erhöhte Sicherheit: Funktionen wie Conditional Access und Multi-Faktor-Authentifizierung sorgen für ein hohes Sicherheitsniveau bei gleichzeitigem Komfort.

Typische Einsatzszenarien

  • Unternehmen mit bestehendem lokalen Active Directory, die Microsoft 365 oder andere Cloud-Dienste einführen

  • Organisationen mit hybrider IT-Infrastruktur (Cloud + On-Premise)

  • Migrationen in die Cloud bei Erhalt der lokalen Authentifizierungslogik

Fazit

Entra ID mit Entra Connect Sync schafft eine nahtlose Verbindung zwischen lokalem AD und der Microsoft Cloud. Es ermöglicht Unternehmen, Identitäten konsistent und sicher über beide Welten hinweg zu verwalten – ein zentraler Baustein moderner Hybrid-IT-Strategien.

Desaster-Recovery-Plan erstellen: So machen Sie Ihre IT krisensicher

Ein IT-Notfall kommt selten mit Vorwarnung – und doch sind viele Unternehmen unzureichend vorbereitet. Ein durchdachter Desaster-Recovery-Plan sichert nicht nur Systeme, sondern auch Ihre Handlungsfähigkeit im Ernstfall. In diesem Beitrag erfahren Sie, wie Sie Ihre IT strukturiert und praxisnah auf Krisenszenarien vorbereiten – von der Analyse über die Kommunikation bis zur Wiederherstellung.

Krisensicher dank Strategie: Ihre Roadmap für ein robustes Desaster-Recovery-Konzept

Ein funktionierendes IT-System ist heute das Rückgrat jedes Unternehmens. Doch genau darin liegt die Gefahr: Wenn alles läuft, fehlt oft der Antrieb, sich auf den Ausnahmezustand vorzubereiten. Dabei ist gerade jetzt der ideale Zeitpunkt, um Strukturen zu hinterfragen, Risiken neu zu bewerten und konkrete Notfallmaßnahmen zu planen.

Denn die zentrale Frage ist nicht ob etwas passiert, sondern wann – und wie gut Sie dann vorbereitet sind.

Teil 1 - Was zählt, wenn es ernst wird

Warum jetzt handeln?

Ob Cyberangriffe, Systemausfälle, Naturkatastrophen oder menschliches Versagen – Szenarien für IT-Desaster gibt es viele. Die Zahl erfolgreicher Angriffe auf mittelständische Unternehmen und Konzerne ist in den letzten Jahren dramatisch gestiegen. Gleichzeitig verlassen sich viele Organisationen auf komplexe Systeme – ohne zu wissen, wie schnell diese im Ernstfall wieder verfügbar wären. Gerade in Zeiten geopolitischer Unsicherheit und zunehmender Digitalisierung ist ein Desaster-Recovery-Plan (DRP) kein „nice to have“, sondern essenzieller Bestandteil einer resilienten Unternehmensstrategie.

Bestandsaufnahme: Was brauche ich wirklich?

Nicht jedes System ist im Notfall gleich wichtig. Die erste Frage muss daher lauten: Welche Prozesse sind geschäftskritisch – und welche Systeme stehen dahinter?
Eine strukturierte Business Impact Analyse (BIA) liefert hier Antworten. Sie zeigt, welche Systeme sehr schnell verfügbar sein müssen (z. B. Warenwirtschaft, Produktionssteuerung, Kommunikation) – und welche und welche Systeme nachgelagert reaktiviert werden können.

Wichtige Fragen dabei:

  • Welche Daten und Prozesse sind für den Fortbestand des Unternehmens unverzichtbar?
  • Wie lange kann der Betrieb ohne bestimmte Systeme aufrechterhalten werden?
  • Was kostet eine Stunde Stillstand – konkret?

Vertrauensgrenzen: Was ist noch sicher – was nicht mehr?

Viele Unternehmen vertrauen blind auf Systeme, die im Notfall selbst zum Problem werden können. Beispiel: Microsoft 365. Was auf den ersten Blick redundant erscheint, ist oft ein Single Point of Failure – denn auch Cloud-Dienste können ausfallen oder Ziel von Angriffen sein.
Ein eigener Exchange-Server im RZ mag altmodisch wirken – bietet aber unter Umständen mehr Kontrolle im Notfall. Entscheidend ist: Wo ziehe ich die Grenze des Vertrauens? Und welche Abhängigkeiten bin ich bereit einzugehen?
Auch hier gilt: Systeme, auf die Sie sich im Notfall verlassen wollen, müssen im Unternehmen durchdacht, getestet und notfalls isoliert lauffähig sein – sei es über eine Private Cloud, Terminalserver oder dedizierte Notfallumgebung.

Zielgrößen: RTO & RPO

Die zwei wichtigsten Kennzahlen im Desaster Recovery:

  • RTO (Recovery Time Objective): Wie schnell muss ein System wieder verfügbar sein?
  • RPO (Recovery Point Objective): Wie alt dürfen die Daten im Worst Case maximal sein?

Ein Beispiel: Wenn Sie Ihre Daten nur einmal täglich sichern, verlieren Sie im Ernstfall bis zu 24 Stunden an Informationen – das ist Ihr RPO. Wenn ein System erst nach 48 Stunden wieder hochgefahren werden kann, ist das Ihr RTO.
Viele Unternehmen definieren diese Werte zu optimistisch – oder gar nicht. Ein realistischer Abgleich zwischen Business-Anforderungen und technischer Machbarkeit ist daher essenziell.

Teil 2 – Kommunikation im Ernstfall: Klarheit statt Chaos

Ein Desaster-Recovery-Plan ist mehr als nur Technik. Einer der häufigsten Fehler in Notfallsituationen ist eine fehlende oder ungeplante Kommunikation – intern wie extern. Dabei entscheidet die richtige Kommunikation darüber, ob ein Vorfall schnell eingegrenzt werden kann oder zum Reputationsrisiko wird.

Wer kommuniziert – und wann?

In der Krise zählt jede Minute. Unklare Zuständigkeiten oder widersprüchliche Aussagen verzögern nicht nur den Wiederanlauf, sondern sorgen für Vertrauensverlust – bei Kunden, Mitarbeitenden und Partnern.
Ein guter DR-Plan definiert deshalb:

  • Verantwortliche Personen für Kommunikation (z. B. Geschäftsführung, IT-Leitung, Pressesprecher)
  • Klare Meldeketten intern – wer informiert wen in welcher Reihenfolge?
  • Vorbereitete Textbausteine für gängige Szenarien (Cyberangriff, Systemausfall, Datenverlust)
  • Kanalstrategie: Wann ist E-Mail sinnvoll, wann besser ein direkter Anruf?

Besonderheit: Kommunikation mit Externen

Spätestens wenn Kunden oder Aufsichtsbehörden betroffen sind, muss das Unternehmen reagieren – und zwar kontrolliert. Eine unüberlegte Aussage wie „Unsere IT wurde gehackt“ kann größere Schäden verursachen als der Vorfall selbst.
Typische externe Kommunikationspartner:

  • Kunden & Lieferanten
  • Presse & Öffentlichkeit
  • Behörden (z. B. Datenschutz, Finanzaufsicht)
  • Versicherungen

Je nach Branche können Meldepflichten bestehen – z. B. bei Datenschutzverletzungen (DSGVO). Auch dafür sollte ein DR-Plan vorbereitet sein.

Sonderfall: Cloud-Ausfälle und SaaS-Dienste

Ein beliebter Irrtum: „Wenn Microsoft 365 ausfällt, ist das nicht unser Problem.“ Doch genau das sehen Kunden und Mitarbeiter oft anders. Wer moderne SaaS-Plattformen nutzt, trägt auch Verantwortung für die Kommunikation im Störfall – selbst wenn die technische Ursache extern liegt.
Daher gilt:

  • Auch Cloud-basierte Dienste brauchen Notfallkommunikationsszenarien
  • Die Verantwortung für Kommunikation bleibt immer beim Unternehmen
  • Externe SLA-Verweise reichen im Ernstfall nicht aus

Praxis-Tipp: Kommunikations-plan als Teil des DR-Konzepts

Ein praxistauglicher Kommunikationsplan besteht idealerweise aus:

  • Kontaktdaten aller relevanten Personen (auch privat / mobil)
  • Kurzanleitungen für häufige Krisenszenarien
  • Templates für Pressemitteilungen und interne Mitteilungen
  • Liste mit Kommunikationsverboten (z. B. keine technischen Details ohne Freigabe)

Ziel: Jeder weiß sofort, was zu tun ist – und niemand muss „im Moment der Krise“ improvisieren.

„Living off the Land“: Die unsichtbare Gefahr aus dem eigenen System

Angriffe, die aussehen wie normale Systemaktivitäten…

Cyberangriffe haben sich verändert. Heute arbeiten viele Angreifer subtiler – sie greifen nicht von außen mit neuen Programmen an, sondern nutzen das, was bereits im Unternehmen vorhanden ist. Dieses Prinzip wird als „Living off the Land“ (LOTL) bezeichnet. Es beschreibt eine Methode, bei der sich Angreifer gezielt jener Tools bedienen, die in jeder Windows-Umgebung zum Alltag gehören: PowerShell, Windows-Dienste, Remote Desktop oder interne Skripte.
Das Heimtückische daran: Diese Werkzeuge sind fester Bestandteil des Betriebssystems und werden regelmäßig von Administratoren oder Wartungsdiensten genutzt. Sie sehen nicht verdächtig aus. Deshalb bleiben sie in vielen Fällen völlig unbemerkt – selbst von erfahrenen IT-Teams oder modernen Sicherheitslösungen.

Wenn der Angreifer kein Fremder mehr ist

Ein LOTL-Angriff beginnt meist mit einem kleinen Türöffner: ein kompromittiertes Benutzerkonto, eine Phishing-Mail, ein ungesicherter Fernzugriff. Von dort aus bewegen sich die Angreifer systematisch weiter – von System zu System, von Dienst zu Dienst. Sie erstellen eigene Skripte, überwachen die Umgebung, sammeln Informationen. Immer mit denselben Bordmitteln, die auch Ihr IT-Team nutzt.

Besonders gefährlich wird es, wenn administrative Rechte ins Spiel kommen. Denn mit diesen Rechten können nicht nur produktive Systeme manipuliert, sondern auch Sicherungssysteme gezielt außer Kraft gesetzt werden. Backups werden gelöscht oder verschlüsselt, Protokolle bereinigt, Alarmierungen deaktiviert. Wenn das Unternehmen den Angriff schließlich entdeckt, ist der eigentliche Schaden oft längst geschehen – und die Wiederherstellung wird zum Wettlauf gegen die Zeit.

Warum klassische Sicherheit hier nicht ausreicht

Die meisten Sicherheitskonzepte setzen auf die Erkennung von fremder Software oder auffälligem Verhalten. Doch bei einem LOTL-Angriff findet beides nicht statt. Alles wirkt legitim – denn es ist legitim. Genau deshalb greifen hier viele Schutzmechanismen ins Leere. Antivirenprogramme schlagen nicht an, weil keine Malware im klassischen Sinne vorliegt. Firewall-Regeln bleiben wirkungslos, weil sich der Angreifer innerhalb des Netzes bewegt. Und Protokolle sind nur hilfreich, wenn sie detailliert genug sind – was in vielen Unternehmen nicht der Fall ist.

Hinzu kommt: Je besser der Angreifer vorbereitet ist, desto unauffälliger verhält er sich. Manche Attacken laufen über Wochen oder Monate – leise, präzise und ohne sichtbare Spuren. Gerade für Unternehmen ohne aktives Monitoring oder ohne Segmentierung im Netzwerk ist das ein enormes Risiko.

Was ein Desaster-Recovery-Plan berücksichtigen muss

Ein moderner Desaster-Recovery-Plan darf sich nicht nur auf äußere Angriffe oder Hardware-Ausfälle konzentrieren. Er muss auch interne Bedrohungsszenarien abbilden – und LOTL ist eines der relevantesten davon. Das bedeutet konkret: Unternehmen müssen wissen, welche administrativen Werkzeuge im Einsatz sind, wer sie nutzen darf, wie sie überwacht werden und wie im Ernstfall schnell und zuverlässig reagiert werden kann.


Zudem sollte geprüft werden, ob Backups wirklich außerhalb des Netzwerks erreichbar sind – oder ob sie bei einem internen Angriff ebenfalls gefährdet wären. Auch Zugriffskonzepte, Rechtevergabe, Protokollierung und Alarmierungen gehören auf den Prüfstand. Wer diese Fragen im Vorfeld klärt, kann im Ernstfall zielgerichtet handeln – statt im Dunkeln zu tappen.


„Living off the Land“ ist eine der gefährlichsten Bedrohungen unserer Zeit – gerade, weil sie schwer zu erkennen ist und auf Systemen basiert, denen wir jeden Tag vertrauen. Doch mit der richtigen Vorbereitung lässt sich das Risiko deutlich reduzieren. Ein sauber geplanter, regelmäßig getesteter Desaster-Recovery-Plan ist dabei der entscheidende Baustein.

Schritt für Schritt: Ihre Roadmap zum Desaster-Recovery-Plan

Struktur statt Aktionismus

Ein Notfallplan bringt nur dann echten Mehrwert, wenn er nicht im Ordner verstaubt, sondern im Ernstfall greift. Doch viele Unternehmen scheitern nicht an der Technik, sondern an der fehlenden Struktur. Es reicht nicht, „irgendetwas“ zu sichern oder ein Backup-Konzept zu haben – entscheidend ist, wer, was, wann und wie wiederherstellt, kommuniziert und entscheidet. Damit der DR-Plan mehr ist als eine technische Skizze, braucht es ein klares Vorgehen. Nicht alles muss sofort umgesetzt werden – aber alles sollte bewusst entschieden und dokumentiert sein.

Phase 1: Bewertung & Priorisierung

Der erste Schritt ist die kritische Selbstbefragung: Welche Systeme sind wirklich überlebenswichtig? Was muss nach einem Ausfall sofort wieder funktionieren – und was kann warten? Dabei hilft eine Business-Impact-Analyse (BIA). Sie stellt die Verbindung zwischen Geschäftsprozessen und IT-Systemen her. Gemeinsam mit den Fachabteilungen wird festgelegt, welche Ausfallzeiten verkraftbar sind – und wo der Betrieb zum Stillstand kommt. Diese Phase ist bewusst nicht technisch. Sie erfordert betriebswirtschaftliches Denken: Welche Kosten entstehen pro Stunde Ausfall? Welche Kundenbeziehungen wären gefährdet? Welche regulatorischen Anforderungen müssen eingehalten werden?

Phase 2: Zieldefinition & Strategie

Sind die Prioritäten klar, geht es an die technischen Zielgrößen: Wie schnell muss ein System wieder laufen (RTO, Recovery Time Objective)? Und wie alt dürfen die Daten maximal sein (RPO, Recovery Point Objective)? Darauf basierend lassen sich konkrete Wiederherstellungsszenarien planen – von einzelnen Applikationen bis hin zum vollständigen Wiederanlauf eines Standorts. Strategien können hybride Wege beinhalten, z. B. ein schneller Start über virtuelle Maschinen in einer Private Cloud, während parallel die physische Infrastruktur wiederhergestellt wird. Auch Optionen wie das Hochziehen einer temporären Umgebung, z. B. via Terminalserver in neuer Domäne, gehören in diesen Plan. Wichtig ist dabei: Jedes Szenario muss realistisch, testbar und dokumentiert sein.

Phase 3: Umsetzung & Tests

Ein Desaster-Recovery-Plan ist nur so gut wie seine Praxisfähigkeit. Darum ist es essenziell, den Ernstfall nicht nur zu simulieren, sondern regelmäßig durchzuspielen – unter realitätsnahen Bedingungen. Tests zeigen nicht nur technische Schwachstellen, sondern auch organisatorische: Wer weiß im Ernstfall, was zu tun ist? Gibt es aktuelle Ansprechpartnerlisten? Wer hat Zugriff auf das Notfallhandy oder auf Offline-Dokumentationen? Parallel dazu müssen die technischen Maßnahmen umgesetzt werden: Backup-Strategien, Notfall-Server, Monitoring, Alarmierungswege, Kommunikationspläne – alles, was im Krisenfall den Unterschied macht.

Phase 4: Dokumentation & Verankerung

Ein DR-Plan ist ein lebendiges Dokument. Er muss regelmäßig aktualisiert, zugänglich gemacht und in die Unternehmensprozesse eingebettet werden. Nur wenn Verantwortlichkeiten klar benannt und Prozesse transparent sind, kann der Plan im Ernstfall greifen.
In dieser Phase sollten auch Schulungen stattfinden – nicht nur für IT, sondern auch für die Fachabteilungen. Denn ein erfolgreicher Wiederanlauf ist keine rein technische, sondern eine unternehmerische Leistung.
Desaster Recovery ist kein Projekt, das man „mal eben“ umsetzt. Aber mit einer strukturierten Roadmap, klaren Prioritäten und realistischen Zielen wird aus einem Risiko ein beherrschbares Szenario. Unternehmen, die vorbereitet sind, gewinnen im Ernstfall nicht nur Zeit – sondern auch Vertrauen, Stabilität und Handlungsfähigkeit.

Fazit: Wer vorbereitet ist, bleibt handlungsfähig

Struktur statt Aktionismus

Ein IT-Notfall kommt selten mit Vorankündigung. Und wenn er eintritt, zählt jede Minute. Unternehmen, die dann einfach in die Schublade greifen und auf einen konkreten, durchdachten Plan zurückgreifen können, sind im Vorteil – operativ, rechtlich und kommunikativ.


Desaster Recovery ist kein rein technisches Thema. Es ist ein strategisches Element moderner Unternehmensführung. Wer seine Systeme kennt, Abhängigkeiten bewertet, Verantwortlichkeiten definiert und Wiederanlaufszenarien durchspielt, ist nicht nur besser geschützt – sondern auch schneller wieder im Geschäft.
Dabei geht es nicht darum, jedes Szenario bis ins letzte Detail zu antizipieren. Vielmehr zählt die Fähigkeit, im Krisenfall schnell, geordnet und wirksam zu handeln. Und genau dafür ist ein guter Desaster-Recovery-Plan gemacht.


Sind Sie vorbereitet? Oder hoffen Sie noch auf Glück?
 Vielleicht läuft Ihre IT derzeit reibungslos. Vielleicht ist der letzte Ausfall schon vergessen. Doch genau jetzt – wenn alles stabil wirkt – ist der beste Zeitpunkt, das Fundament für den Ernstfall zu legen.
Denn die zentrale Frage ist nicht ob etwas passiert, sondern wie gut Sie darauf vorbereitet sind.

Jetzt handeln – mit einem starken Partner an Ihrer Seite

Bei KNS – Kurfer Network Support unterstützen wir Unternehmen seit Jahren dabei, ihre IT-Infrastruktur nicht nur leistungsfähig, sondern auch krisenfest aufzustellen. Wir kombinieren technische Kompetenz mit strategischem Denken – für Lösungen, die nicht nur im Normalbetrieb, sondern auch im Ausnahmezustand funktionieren.

Ob Analyse Ihrer aktuellen Systeme, Erstellung eines individuellen Desaster-Recovery-Plans oder Aufbau einer resilienten Private-Cloud-Umgebung – wir begleiten Sie persönlich, verlässlich und lösungsorientiert.

Vereinbaren Sie ein unverbindliches Erstgespräch.

Gemeinsam klären wir, wie Ihr Unternehmen im Notfall handlungsfähig bleibt – ohne blinden Aktionismus, aber mit klarer Struktur.