IT-Sicherheit durch stetige Veränderung

Always change a ­running system

| Autor / Redakteur: Sven Malte Sopha & Jan Graßhoff* / Susanne Ehneß

Sicherheit muss als Prozess verstanden werden und bedarf der kontinuierlichen Verbesserung. Der neue Grundsatz sollte also lauten: Always change a running system.
Sicherheit muss als Prozess verstanden werden und bedarf der kontinuierlichen Verbesserung. Der neue Grundsatz sollte also lauten: Always change a running system. (Bild: Pixabay)

Computersysteme haben Einzug in alle Lebensbereiche gehalten. Durch ihren Einsatz wurde und wird unser Leben zweifelsohne einfacher. In vielen Fällen sind wir von diesen Systemen abhängig und müssen uns auf eine ordnungsgemäße Funktion verlassen – von der Fahrzeugsteuerung im PKW bis zur digitalen Zutrittssteuerung im Büro.

Die Eigenschaften von IT-Systemen werden maßgeblich durch ihre Software festgelegt. So unterschiedlich Softwareprodukte sein können, eines haben sie gemeinsam: Alle enthalten Fehler, die zu Sicherheitslücken führen können. Wer diesem Problem sinnvoll begegnen will, muss sich von dem ­alten Grundsatz „Never change a running system“ verabschieden. Wer seine IT-Systeme wirklich schützen will, muss Sicherheit als kontinuierlichen Prozess verstehen – und in der Organisation entsprechend verankern.

Die bekannte Sicherheitslücke wird gefährlich

Der Ursprung von Fehlern und ­Sicherheitslücken in IT-Systemen kann vielfältig sein. So fand beispielsweise ein Hacker im Jahr 2008 heraus, dass eine unzureichende Spezifizierung in den Kassensystemen des Discounters Lidl zu deren Absturz führen konnte. Die im April 2014 bekannt gewordene Schwachstelle in der Verschlüsselungsbibliothek OpenSSL mit dem Namen „Heartbleed“ ­resultierte hingegen aus einem ­Implementierungsfehler.

In der Regel stellen Hersteller Software-­Updates bereit, die bekannt gewordene Fehler beheben sollen. Gleichzeitig werden im Internet aber Informationen und Werkzeuge zur Ausnutzung dieser Sicherheits­lücken gehandelt. Da eine Schwachstelle zum Zeitpunkt der Bereitstellung einer Fehlerbehebung (oder kurz danach) meist ­öffentlich bekannt ist, können Angreifer sie aktiv ausnutzen.

Die Betreiber von IT-Systemen sind daher gut beraten, Aktualisierungen zeitnah einzuspielen. Dies ist im Fall von regulärer Anwendungssoftware auf einem PC vergleichsweise einfach – kann im Fall von dezentralen und nicht vernetzen Systemen jedoch einen erheblichen Aufwand bedeuten. Ein aktuelles Beispiel dafür ist die Rückruf­aktion von VW, bei der wegen des Abgasskandals allein in Deutschland hunderttausende Fahrzeuge zum Software-Update in die Werkstatt müssen.

Veraltete IT-Systeme – ­keine Seltenheit

In der Realität funktionieren Updateprozesse oft nicht reibungslos. In einigen Fällen stellen Softwarehersteller Aktualisierungen gar nicht oder nicht zeitnah zur Verfügung. Spätestens wenn ein Produkt den regulären Lebens­zyklus verlässt, werden keine neuen Versionen mehr bereitgestellt. In anderen Fällen scheitert der Prozess auf Seiten des Systembetreibers – aus vielfältigen Gründen: etwa zu hohe Komplexität beim Aktualisierungsvorgang, fehlende Prozesse, mangelndes Bewusstsein oder wegen Kompatibilitätsproblemen.

Ergänzendes zum Thema
 
Always change a ­running system

Sehr schnell reagieren mussten Administratoren auf die erwähnte „Heartbleed“-Schwachstelle in OpenSSL. Hier führt ein Programmierfehler dazu, dass Angreifer verschlüsselte Kommunikation mitlesen können. Sicherheits-Experten wie Bruce Schneier bezeichneten die Auswirkungen der Schwachstelle als Katastrophe. In Anbetracht dieser Bedrohungslage sollten Administratoren ihre Systeme eigentlich zeitnah aktualisieren. Doch eine Studie der Cyber­security-Firma Venafi aus dem Jahr 2015 zeigt, dass selbst zwölf Monate nach Bekanntwerden von Heartbleed der Großteil der öffentlich erreichbaren Server der 2.000 größten Unternehmen weiterhin verwundbar blieb.

Windows XP: Ablösung eine Herausforderung

Plötzlich bekannt werdende Sicherheitslücken stellen alle Organisationen, ob aus der Privatwirtschaft oder der Öffentlichen Verwaltung, vor große Herausforderungen. Mitunter auch noch dann, wenn der Handlungsbedarf schon lange bekannt und geplant ist – wie beim Supportende für das Betriebssystem Windows XP. Das Ende des Lifecycles wurde von Microsoft einige Jahre im Voraus angekündigt. Dennoch hatten und haben große Organisationen ihre Schwierigkeiten mit der Umstellung von Windows XP auf Windows 7, etwa auch der Deutsche Bundestag und die Berliner Landesverwaltung.

Windows XP läuft aber nicht nur auf gewöhnlichen Rechnern, sondern auch auf speziellen Geräten mit besonderen Aufgaben, wie in der Medizintechnik. Ist der Lifecycle der Hardware aber länger als der der sie steuernden Software, behalten diese Geräte meist das veraltete Betriebssystem, und die neu entdeckten Sicherheitslücken der Software werden nicht geschlossen – obwohl in der Medizintechnik Sicherheit eine übergeordnete Rolle spielt.

Lebenszyklen von Hard-/Software synchronisieren

Sven Malte Sopha
Sven Malte Sopha (Bild: Cassini)

Bei Geldautomaten ist es ähnlich. 95 Prozent dieser Systeme werden mit Windows XP betrieben, auch sie können nicht ohne weiteres auf neue Versionen migriert werden. Während die Deutsche Kreditwirtschaft die fehlende Verbindung der Geldautomaten ins öffentliche Internet als Sicherheitsmerkmal ansieht – wodurch auf Windows XP basierende Geräte weiterhin sicher betrieben werden könnten –, ist Kaspersky Labs der gegenteiligen Auffassung: Fast alle Geldautomaten seien wegen des veralteten Windows XP für Angriffe anfällig.

Strukturiertes Sicherheits- und Patchmanagement

Weil neue Sicherheitslücken jederzeit entdeckt werden können, ist es unzureichend, Systeme nur einmalig abzusichern. Die Frage, ob Systeme ausreichend abgesichert sind, muss kontinuierlich gestellt werden. Diese regelmäßige Überprüfung ist als betriebliche Aufgabe zu verstehen. Auf Grund der Komplexität und der Abhängigkeit von Komponenten und Systemen kann die Wirksamkeit der Absicherung erst nach Prüfung aller gemeinsam agierenden Sicherheitsmaßnahmen bewertet werden.

Die Herausforderung für alle Organisationen – auch für Behörden und Öffentliche Verwaltungen – besteht darin, ein Managementsystem zu etablieren, um diese Überprüfung im Rahmen der betrieblichen Aufgaben durchzuführen. Es ist entscheidend, bei Bedarf die notwendigen Änderungen in einem strukturierten Verfahren vornehmen zu können, ohne dabei den Betrieb und andere Systeme zu gefährden. Ein Sicherheits- und Patchmanagement (SuP), das in der Organisation verankert und standardisiert ist, kann die übergreifende Struktur für Abteilungen und Fachbereiche bieten.

Zentrale Aufgabe des SuP ist es, sowohl planbare als auch nicht planbare, kurzfristige Änderungen an Systemen umzusetzen. Dies kann nicht nur Software-, sondern auch Hardwarekomponenten oder betriebliche Abläufe betreffen. Hier gilt es, Abhängigkeiten zu betrachten, um ungewollte Ausfälle von Diensten im Rahmen von Aktualisierungen zu vermeiden.

Änderungen an Systemen ohne Abhängigkeiten lassen sich innerhalb der Organisationseinheit umsetzen. Für größere, komplexere Änderungen ist es allerdings ratsam, ein übergreifendes Gremium zu etablieren. Ein Change Advisory Board (CAB), das standardisierte, aufeinander abgestimmte Abläufe und geregelte Verantwortlichkeiten aufweist, kann eingereichte Änderungsanträge strukturiert bearbeiten.

In der Praxis hat es sich bewährt, in ein CAB alle relevanten Bereiche einzubeziehen – auch Stabsfunktionen wie IT-Sicherheitsbeauftragter und Datenschützer. Entscheidungen, etwa zur Einspielung von Software-Updates oder Hardwarewechseln, lassen sich dann unter Berücksichtigung aller betrieblichen und sicherheitsrelevanten Abhängigkeiten treffen.

Lifecycle Management: Sicherheit & ausmustern

In Organisationen kommen meist unterschiedliche IT-Systeme und Komponenten zum Einsatz, für die in der Regel verschiedene Fachbereiche zuständig sind. Jede Hardwarekomponente hat einen Lifecycle. In Abhängigkeit davon findet der Herstellersupport statt – und die Bereitstellung neuer Softwareversionen, die Fehler beseitigen oder den Funktionsumfang erweitern. Fehlende (Sicherheits-)Funktionalitäten in einer Komponente können aber nicht immer durch eine einfache Aktualisierung der Firmware nachgerüstet werden. Neue kryptografische Algorithmen etwa lassen sich nur dann per Software-Update aufspielen und nutzen, wenn die eingesetzte Hardware dies auch unterstützt. Sollen jeweils aktuelle kryptografische Algorithmen eingesetzt werden, ist meist ein bedarfsgerechter Austausch von Komponenten erforderlich. Es gilt darum, neue Beschaffungen in Abstimmung mit den fachlich verantwortlichen Bereichen frühzeitig zu planen.

Jan Graßhoff
Jan Graßhoff (Bild: Cassini)

Im Fokus dürfen dabei nicht nur funktionale Anforderungen stehen, sondern primär auch strategische und sicherheitsrelevante Anforderungen. Ein Paradebeispiel für das Ende eines Software-Lifecycles liefert das GSTOOL vom BSI. Im Oktober 2014 kündigte das BSI die Einstellung und das Supportende von GSTOOL zum Ende des Jahres 2016 an. Die Nutzer sind seitdem aufgefordert, die Außerbetriebnahme ihrer GSTOOL-Instanz vorzubereiten und auf ein anderes ISMS-Tool zu migrieren – zumal ein solches Tool auch für die Öffentliche Verwaltung ein wesentlicher Baustein in der Sicherheitsorganisation ist.

Sicherheit durch stetige Veränderung

Organisationen müssen die Herausforderungen bei der IT-Sicherheit gesamtheitlich betrachten und neben technischen Fragestellungen auch ihre Prozesse aufeinander abstimmen. Hier hat sich die Etablierung von standardisierten Prozessen bewährt. Dabei gilt das Prinzip: Nach der Absicherung ist vor der Absicherung. Es ist erforderlich, Sicherheitsmaßnahmen kontinuierlich zu überwachen und in Frage zu stellen. Dies müssen Organisationen als betriebliche Aufgabe verstehen – und entsprechend einplanen und umsetzen.

Es ist unerlässlich, IT-Systeme mit derselben Sorgfalt zu warten, wie sie etwa bei technischen Anlagen in der Industrie oder bei PKWs in Privathaushalten selbstverständlich ist.

Auch das BSI hat die neuen Herausforderung erkannt und mit der Modernisierung des IT-Grundschutzes reagiert. Durch das neue Werkzeug des BSI, das ab 2017 verfügbar sein soll, soll die Absicherung von Komponenten und Prozessen zielgerichteter und schneller erfolgen können.

Der alte Grundsatz „Never change a running system“ bietet eine unnötig große Angriffsfläche. Produktive Systeme müssen immer angefasst und angepasst werden. Eine Organisation, in der der Wille zur stetigen Weiterentwicklung mit ausreichenden Ressourcen untermauert wird, schafft die Voraussetzung für einen sicheren und zukunftsfähigen Betrieb.

Sicherheit muss als Prozess verstanden werden und bedarf der kontinuierlichen Verbesserung. Der neue Grundsatz sollte also lauten: Always change a running system.

* Die Autoren: Sven Malte Sopha, Senior Consultant & Jan Graßhoff, Consultant, Cassini Consulting GmbH

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44234725 / Betriebssystem)