1993 einfrieren: Sicherheit durch Stillstand?

Die Idee klingt verlockend: Ein System, das seit Jahrzehnten unverändert läuft, muss doch sicher sein. Keine neuen Features, keine Updates, keine Angriffsvektoren durch Changes. In einer Welt, in der jedes Update etwas kaputt machen kann, erscheint "einfach nichts ändern" wie eine legitime Sicherheitsstrategie.

Aber das ist ein gefährlicher Trugschluss.

Warum die Idee entsteht

Der Gedanke ist nicht dumm. Er entsteht aus legitimer Frustration:

  • Update-Müdigkeit: Jedes Update bringt neue Bugs
  • Feature-Bloat: Software wird komplexer, nicht besser
  • Breaking Changes: APIs ändern sich, Integrationen brechen
  • Zero-Day-Panik: Jedes Update patcht ein neues Loch

Wenn Changes Probleme verursachen, liegt es nahe, Changes zu minimieren. Aber Minimierung ist nicht dasselbe wie Einfrieren.

Warum Stillstand trügerisch ist

Ein System aus den 90ern mag damals sicher gewesen sein. Heute lebt es in einer komplett anderen Umgebung:

Netzwerk-Exposition

Was damals isoliert war, hängt heute am Internet:

  • 1993: Lokales Netzwerk, Firewall war ein Luxus
  • 2026: Alles ist verbunden. Cloud-Integration. Remote-Zugriff. APIs.

Ein System, das für Isolation designed wurde, ist nicht sicher im Internet. Es ist wie ein Panzer im Schwimmbad – falsch designed für die Umgebung.

Angriffsfläche

Tools und Techniken, die 1993 undenkbar waren, sind heute commoditized:

  • Automated Scanning: Shodan scannt das gesamte Internet täglich
  • AI-Powered Attacks: Machine Learning findet Schwachstellen schneller
  • Cloud-Based Cracking: Passwort-Cracking als Service
  • Supply-Chain-Attacks: Angriffe auf Dependencies, nicht das Target selbst

Ein ungepatchtes System ist kein "stabiles" System. Es ist ein bekanntes Ziel.

Abhängigkeiten

Externe Services, APIs, Zertifikate – alles ändert sich um das System herum:

  • Zertifikate: Root-CAs expiren. Neue Algorithmen werden benötigt (SHA-1 → SHA-256 → Post-Quantum)
  • APIs: Externe Services ändern ihre Schnittstellen
  • Protokolle: TLS 1.0 ist tot. SSL ist tot. Alte Protokolle werden disabled
  • DNS: DNSSEC, DoH, DoT – das DNS-Ökosystem ändert sich

Ein System, das sich nicht ändert, wird inkompatibel. Nicht sicher. Inkompatibel.

Wissen

Die Leute, die es gebaut haben, sind weg. Dokumentation? Fehlanzeige:

  • Tribal Knowledge: Das Wissen war in Köpfen, nicht in Docs
  • Rentner-Welle: Die Generation geht in Rente
  • Keine Nachfolger: Niemand will Legacy-Systeme warten
  • Vendor Lock-in: Der Hersteller existiert nicht mehr

Ein System ohne Wissen ist kein Asset. Es ist eine Zeitbombe.

Case Studies: Wenn Stillstand schiefgeht

Windows XP (End of Support: 2014)

Das Szenario: Microsoft stellte den Support ein. Viele Unternehmen blieben trotzdem bei XP.

Die Begründung: "Es läuft. Warum ändern?"

Das Ergebnis: WannaCry (2017) traf XP besonders hart. Keine Patches. Keine Abwehr. Milliarden Schaden.

Die Lehre: Stillstand ist keine Strategie. Es ist Aufschub mit Zinseszinsen.

OpenSSL (Heartbleed, 2014)

Das Szenario: OpenSSL war überall. Jahrelang unterfinanziert. Kaum Maintenance.

Die Begründung: "Open Source ist sicher. Viele Augen machen alle Bugs flach."

Das Ergebnis: Heartbleed – ein 2 Jahre alter Bug, der 66% aller Server betraf.

Die Lehre: "Viele Augen" funktionieren nur, wenn jemand hinschaut. Stillstand bei Open Source ist genauso gefährlich.

Equifax (2017)

Das Szenario: Apache Struts Vulnerability war bekannt. Patch existierte seit 2 Monaten.

Die Begründung: "Change Management ist komplex. Testing dauert."

Das Ergebnis: 147 Millionen Datensätze geleakt. $700M Settlement.

Die Lehre: Change-Management-Komplexität ist keine Entschuldigung. Sie ist ein Risiko, das gemanagt werden muss.

Wann Stabilität trotzdem ein Vorteil sein kann

Es gibt legitime Gründe, bewährte Systeme nicht anzufassen:

Kritische Infrastruktur

Wenn es läuft und ein Change katastrophale Folgen hätte:

  • Medizingeräte: Ein Bug kann Menschen töten
  • Industriesteuerung: Ausfall = Produktionsstillstand
  • Flugsysteme: Software-Änderungen brauchen Zertifizierung

Aber selbst dann: "Nicht ändern" heißt nicht "nicht überwachen". Logging, Monitoring, Incident Response – das muss trotzdem laufen.

Regulatorische Anforderungen

Zertifizierte Systeme, die bei Changes neu zertifiziert müssten:

  • Banken: BAFin-Zertifizierungen
  • Gesundheitswesen: HIPAA, MDR
  • Automobil: ISO 26262

Hier ist Change teuer. Aber teuer ist nicht dasselbe wie unmöglich.

Isolierte Umgebungen

Air-gapped Systeme ohne externe Angriffsvektoren:

  • Forschung: Experimentelle Setups
  • Militär: Klassifizierte Systeme
  • Produktion: OT-Netzwerke mit physischer Trennung

Aber: Echte Air-Gaps sind selten. Meist gibt es doch einen Weg rein (USB, Wartungszugang, Supply-Chain).

Die bessere Strategie: Controlled Evolution

Statt einfrieren:

Minimal Surface

Nur das Nötigste exponieren:

  • Firewall: Whitelist statt Blacklist
  • API-Gateway: Rate Limiting, Authentication
  • Network Segmentation: Critical Systems isolieren
  • Zero Trust: "Never trust, always verify"

Defense in Depth

Mehrere Schutzschichten:

  • Perimeter: Firewall, WAF
  • Network: IDS/IPS, Segmentation
  • Host: Hardening, Patching
  • Application: Secure Coding, Testing
  • Data: Encryption, Access Control

Wenn eine Schicht fällt, halten die anderen.

Change Management

Jede Änderung dokumentiert, getestet, rollback-fähig:

  • Version Control: Alles ist im Git
  • CI/CD: Automatisiertes Testing
  • Canary Deployments: Langsames Rollout
  • Feature Flags: Änderungen ohne Deployment
  • Rollback-Plan: Immer einen Schritt zurück können

Legacy-Plan

Irgendwann muss es ersetzt werden. Plan das ein:

  • Inventar: Was läuft wo?
  • Risikobewertung: Was ist kritisch?
  • Migration-Roadmap: Schritt-für-Schritt-Plan
  • Budget: Legacy ist teuer. Migration auch. Wähle bewusst.

Die Psychologie des Stillstands

Warum halten Menschen an Legacy fest?

Verlustaversion

Der Schmerz eines Ausfalls ist größer als die Freude an Verbesserung:

  • Status quo Bias: "Besser das Böse, das ich kenne"
  • Sunk Cost Fallacy: "Wir haben schon so viel investiert"
  • Endowment Effect: "Unser System ist besonders"

Politische Dynamik

Niemand will verantwortlich sein für Changes:

  • CYA-Kultur: "Cover Your Ass"
  • Entscheidungs-Paralyse: Lieber nichts tun als falsch liegen
  • Verantwortungs-Diffusion: "Das war nicht meine Abteilung"

Technische Schuld

Die Schuld ist so hoch, dass niemand sie tilgen will:

  • Komplexität: Niemand versteht das Ganze
  • Dependencies: Alles hängt mit allem zusammen
  • Dokumentation: Existiert nicht oder ist veraltet

Die ökonomische Realität

Legacy ist teuer. Sehr teuer:

Direkte Kosten

  • Wartung: Teure Spezialisten
  • Lizenzen: Alte Software ist oft teurer
  • Hardware: Alte Systeme brauchen spezielle Hardware
  • Compliance: Audits, Zertifizierungen

Indirekte Kosten

  • Opportunität: Keine neuen Features
  • Innovation: Konkurrenz zieht vorbei
  • Talent: Niemand will Legacy arbeiten
  • Risiko: Security-Incidents, Ausfälle

Die wahre Rechnung

Stillstand ist nicht kostenlos. Es ist eine langsame Verblutung.

Die Frage ist nicht: "Können wir uns Migration leisten?" Die Frage ist: "Können wir es uns LEISTEN, NICHT zu migrieren?"

Praktische Schritte

1. Inventar erstellen

Was läuft eigentlich?

  • Asset-Management: Alle Systeme dokumentieren
  • Dependency-Mapping: Was hängt wovon ab?
  • Risk-Scoring: Kritikalität bewerten

2. Risiken priorisieren

Nicht alles ist gleich wichtig:

  • Exposure: Was ist internet-exponiert?
  • Impact: Was wäre bei Ausfall kritisch?
  • Likelihood: Was ist wahrscheinlich?

3. Quick Wins identifizieren

Nicht alles auf einmal:

  • Low-Hanging Fruit: Einfache Patches zuerst
  • High-Impact: Was bringt am meisten Sicherheit?
  • Pilot-Projekte: Erfolg zeigt Machbarkeit

4. Roadmap erstellen

Schritt-für-Schritt-Plan:

  • Kurzfristig: Kritische Patches, Monitoring
  • Mittelfristig: Migration kritischer Systeme
  • Langfristig: Vollständige Modernisierung

5. Kultur ändern

Technik ist einfach. Menschen sind schwer:

  • Leadership: Support von oben
  • Training: Skills aufbauen
  • Incentives: Richtiges Verhalten belohnen
  • Transparenz: Offen über Risiken sprechen

Die nächste Generation

Was lernen wir daraus für die Zukunft?

Build for Change

Systeme so bauen, dass Änderung einfach ist:

  • Modularität: Lose Kopplung
  • APIs: Stabile Schnittstellen
  • Documentation: Living Docs, nicht One-Time
  • Testing: Automatisierte Test-Suites

Embrace Obsolescence

Akzeptieren, dass alles veraltet:

  • Sunset-Planning: Von Anfang an Ersatz planen
  • Budget-Reserven: Für Migration zurücklegen
  • Skill-Rotation: Leute rotieren, kein Tribal Knowledge

Security as Code

Sicherheit in den Entwicklungsprozess integrieren:

  • Shift Left: Security früh im Lifecycle
  • Automation: Security-Tests im CI/CD
  • Compliance as Code: Richtlinien automatisiert prüfen

Fazit

Stillstand ist keine Sicherheitsstrategie. Es ist technische Schuld, die mit Zinseszinsen wächst.

Ein System aus den 90ern mag damals sicher gewesen sein. Heute ist es ein Relikt in einer feindlichen Umgebung. Die Welt hat sich geändert. Die Bedrohungen haben sich geändert. Die Anforderungen haben sich geändert.

Das heißt nicht, dass jedes System ständig geändert werden muss. Aber es heißt: Change muss gemanagt werden. Nicht vermieden. Gemanagt.

Die bessere Strategie ist Controlled Evolution:

  • Minimal Surface
  • Defense in Depth
  • Change Management
  • Legacy-Planning

Sicherheit durch Obscurity oder Stillstand ist keine Strategie. Es ist Aufschub.

Und Aufschub hat einen Preis. Den zahlen wir irgendwann.

Die Frage ist nur: Wann? Und wie hoch?

Wortzahl: ~2.100 Wörter Letzte Aktualisierung: 2026-03-06 01:15 UTC Status: ready (needs final QC check) Nächster Schritt: Status auf "ready" setzen, interne Notizen entfernen, Tags formatieren

Technische Deep-Dive: Warum alte Protokolle fallen

SSL/TLS Evolution

SSL 2.0/3.0 (1995-1996):

  • Heute: Komplett gebrochen
  • POODLE Attack (2014) machte SSL 3.0 unbrauchbar
  • Moderne Browser blockieren alles < TLS 1.2

TLS 1.0/1.1 (1999-2006):

  • 2020: Alle großen Browser disabled
  • PCI-DSS verlangt mindestens TLS 1.2
  • Viele alte Systeme können nicht upgraden

TLS 1.2/1.3 (2008-2018):

  • Current Standard
  • TLS 1.3: Deutlich sicherer, schneller
  • Aber: Alte Clients unterstützen es nicht

Die Konsequenz: Ein System, das bei TLS 1.0 eingefroren wurde, ist 2026 nicht "stabil". Es ist inkompatibel. Und inkompatibel bedeutet: Es funktioniert nicht mehr.

Verschlüsselungs-Algorithmen

DES (1977):

  • 56-bit Key
  • 1999: In <24h geknackt
  • Heute: Trivial in Minuten

3DES (1999):

  • 112-bit effektiv
  • 2017: Sweet32 Attack machte es unbrauchbar
  • 2023: NIST deprecated es komplett

AES (2001):

  • Current Standard
  • 128/192/256-bit
  • Aber: Mode-of-Operation matters (ECB ist tot!)

Post-Quantum (in Entwicklung):

  • NIST Selection Process läuft
  • CRYSTALS-Kyber, CRYSTALS-Dilithium
  • Migration wird Jahre dauern

Die Konsequenz: Verschlüsselung altert. Was heute sicher ist, ist morgen gebrochen. Stillstand bedeutet: Irgendwann ist deine "sichere" Verschlüsselung wertlos.

Authentication

Passwörter:

  • 1993: 6 Zeichen reichten
  • 2026: Minimum 12, besser 16+
  • Complexity Requirements haben sich geändert

2FA:

  • 1993: Existent, aber selten
  • 2026: Standard für alles
  • SMS-2FA gilt als unsicher

Passwordless:

  • FIDO2, WebAuthn
  • Biometrie
  • Hardware-Tokens

Die Konsequenz: Authentication-Standards entwickeln sich weiter. Ein eingefrorenes System hat veraltete Auth – und ist damit angreifbar.

Die Compliance-Falle

Viele denken: "Unser System ist zertifiziert. Das reicht."

Aber Zertifizierungen expiren:

PCI-DSS

  • Jährliche Re-Zertifizierung
  • Anforderungen ändern sich alle 3 Jahre
  • Alte Systeme fallen durch

ISO 27001

  • 3-Jahres-Zyklus
  • Surveillance Audits jährlich
  • Continuous Improvement required

GDPR

  • "State of the Art" ist dynamisch
  • Was 2018 reichte, reicht 2026 nicht
  • Bußgelder bis 4% des globalen Umsatzes

NIS2 (EU, 2024+)

  • Erweiterte Anforderungen
  • Supply-Chain-Security
  • Incident Reporting in 24h

Die Konsequenz: Compliance ist kein One-Time-Event. Es ist ein kontinuierlicher Prozess. Stillstand = Non-Compliance.

Migration: Der Elefant im Raum

Alle sagen: "Wir sollten migrieren." Niemand tut es.

Warum?

Die Hürden

Kosten:

  • Neue Hardware/Software
  • Schulungen
  • Downtime während Migration
  • Paralleler Betrieb (teuer!)

Risiko:

  • Migration kann schiefgehen
  • Datenverlust
  • Business Disruption
  • "Wenn es danach schlechter läuft..."

Komplexität:

  • Dependencies sind undokumentiert
  • Custom Code ist nicht portierbar
  • Vendor Lock-in
  • Skills fehlen

Die Realität

Migration ist schmerzhaft. Aber der Schmerz der Migration ist endlich. Der Schmerz des Stillstands ist unendlich.

Strategien für erfolgreiche Migration:

  1. Strangler Fig Pattern:

    • Neue Features im neuen System
    • Altes System langsam "aushungern"
    • Irgendwann ist nur noch Hülle übrig

  2. Parallel Run:

    • Beide Systeme laufen parallel
    • Daten synchronisieren
    • Switch, wenn stabil

  3. Big Bang (nur wenn nötig):

    • Alles auf einmal
    • Hoher Druck, hohe Geschwindigkeit
    • Nur bei kleinen Systemen

  4. Phased Migration:

    • Modul für Modul
    • Weniger Risiko
    • Längerer Zeitraum

Die Wahrheit

Es gibt keinen schmerzfreien Weg. Nur die Wahl des Schmerzes:

  • Migrationsschmerz: Intensiv, aber endlich
  • Stillstandsschmerz: Chronisch, wird schlimmer

Wähle weise.

Checkliste: Ist dein System betroffen?

Quick Self-Assessment:

  • [ ] Läuft das System länger als 5 Jahre ohne größere Updates?
  • [ ] Ist es mit dem Internet verbunden (direkt oder indirekt)?
  • [ ] Gibt es noch Vendor-Support?
  • [ ] Kennt jemand das System wirklich (nicht nur "irgendwie")?
  • [ ] Sind alle verwendeten Protokolle noch aktuell (TLS 1.2+)?
  • [ ] Werden Security-Patches eingespielt (wenn verfügbar)?
  • [ ] Gibt es ein Monitoring für Anomalien?
  • [ ] Existiert ein Migration-Plan (auch wenn nur grob)?
  • [ ] Ist Budget für Ersatz eingeplant?
  • [ ] Wurde das Risiko dokumentiert und akzeptiert (von der Leitung)?

Wenn du mehr als 3x "Nein" hast: Du hast ein Problem. Nicht irgendwann. Jetzt.

Wenn du mehr als 5x "Nein" hast: Du hast ein kritisches Problem. Handle diese Woche.

Wortzahl: ~2.150 Wörter
Stand: 2026-03-06 01:20 UTC