Alarm. Freitag, 16:35 Uhr. Mehrere Sachbearbeiter des Unternehmens „OCRON“ stehen im Büro der Administratoren und beklagen, dass Sie mit ihren Computern nicht mehr arbeiten können. Erst haben die Server keine Eingaben mehr entgegen genommen und plötzlich schalteten sich alle Bildschirme der Sachbearbeiter gleichzeitig ab, dabei wollen doch alle pünktlich in ihr Wochenende starten. Auch die Administratoren haben bereits automatische Warnmeldungen bekommen, dass einige Systeme nicht mehr richtig arbeiten, da bestimmte Dienste sich nicht mehr starten lassen. Es ist auch erkennbar, dass die Server scheinbar willkürlich Daten an Systeme im Internet weiterleiten. Ein Virus scheint die Systeme übernommen zu haben und das, obwohl die Administratoren die Betriebssysteme doch immer auf dem neuesten Stand gehalten haben. Die schädliche Software muss durch ein anderes Programm in den Betrieb gelangt sein. Die Systeme müssen heruntergefahren werden und die Wartungsarbeiten halten die Administratoren für dieses Wochenende vom Heimweg ab.
Dieses praxisnahe Beispiel zeigt, dass nicht nur Betriebssysteme auf dem aktuellsten Stand gehalten werden müssen, sondern jedes Programm, welches im Unternehmen benutzt wird. Ein zentrales Patch-Management hätte alle bekannten Sicherheitslücken teilweise sogar automatisch geschlossen und hätte das Wochenende für die Administratoren sicherlich angenehmer gemacht.
Diese Wissenschaftliche Arbeit ist eine Praxisreflexion im Rahmen eines Dualen Studiums, die in 3 Abschnitte gegliedert ist. Im ersten Abschnitt werden die theoretischen Grundlagen, mit Hilfe von Fachliteratur, betrachtet und erläutert. Im zweiten Teil der Arbeit wird die aktuelle Situation im Betrieb analysiert, worauf im dritten Teil Optimierungspotenziale für den Betrieb erarbeitet werden. Aufgrund der firmeninternen Daten darf hier nur der Theorieabschnitt veröffentlicht werden. Die angegebene Note bezieht sich natürlich auf die komplette Wissenschaftliche Arbeit.
Inhaltsverzeichnis
Abbildungsverzeichnis
1 Einführung
2 Charakteristische Merkmale des Patch-Managements
2.1 Definition und Ziele des Patch-Managements
2.2 Einordnung in das Change-Management
2.3 Der Patch-Management-Prozess
2.4 Herausforderungen beim Patch-Management
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: Aufgaben des Change-Management-Prozesses
Abbildung 2: Vierphasenansatz des Patch-Management-Prozesses
1 Einführung
Alarm. Freitag, 16:35 Uhr. Mehrere Sachbearbeiter des Unternehmens „OCRON“[1] stehen im Büro der Administratoren und beklagen, dass Sie mit ihren Computern nicht mehr arbeiten können. Erst haben die Server keine Eingaben mehr entgegen genommen und plötzlich schalteten sich alle Bildschirme der Sachbearbeiter gleichzeitig ab, dabei wollen doch alle pünktlich in ihr Wochenende starten. Auch die Administratoren haben bereits automatische Warnmeldungen bekommen, dass einige Systeme nicht mehr richtig arbeiten, da bestimmte Dienste sich nicht mehr starten lassen. Es ist auch erkennbar, dass die Server scheinbar willkürlich Daten an Systeme im Internet weiterleiten. Ein Virus scheint die Systeme übernommen zu haben und das, obwohl die Administratoren die Betriebssysteme doch immer auf dem neuesten Stand gehalten haben. Die schädliche Software muss durch ein anderes Programm in den Betrieb gelangt sein. Die Systeme müssen heruntergefahren werden und die Wartungsarbeiten halten die Administratoren für dieses Wochenende vom Heimweg ab.
Dieses praxisnahe Beispiel zeigt, dass nicht nur Betriebssysteme auf dem aktuellsten Stand gehalten werden müssen, sondern jedes Programm, welches im Unternehmen benutzt wird. Ein zentrales Patch-Management hätte alle bekannten Sicherheitslücken teilweise sogar automatisch geschlossen und hätte das Wochenende für die Administratoren sicherlich angenehmer gemacht.
2 Charakteristische Merkmale des Patch-Managements
2.1 Definition und Ziele des Patch-Managements
Der Aspekt „Sicherheit“ ist zurzeit das Top-Thema für Unternehmen weltweit. Meist wird hierfür der Fokus ausschließlich auf AntiViren-Programme und Firewalls gelegt. Zusätzlich ist es aber mindestens genauso wichtig, Benutzer im Umgang mit Software zu sensibilisieren, sowie IT-Mitarbeiter zu trainieren, um schädliche Programme von vornherein zu identifizieren. Ein Schlüsselthema für erfolgreiche Sicherheit ist allerdings auch das Patch-Management.[2]
Betriebssysteme, Programme und vor allen Dingen AntiViren-Software bieten nur dann optimalen Schutz oder geringste Angreifpunkte, wenn Sie auf dem aktuellen Stand sind. „Patch“ kommt aus dem Englischen und steht für „Flicken“. Patches sind sowohl kleinere als auch größere Softwarepakete, mit denen Hersteller Sicherheitslücken schließen wollen. Sicherheitslücken beschreiben Schwachstellen in einer Software, durch die ein potenzieller Angreifer versuchen kann, schädliche Programme in das System zu bringen um dann Kontrolle über dieses zu erlangen und Schaden zuzufügen.[3]
Bekannte Sicherheitslücken werden gerne ausgenutzt, um Systeme anzugreifen. Wenn diese Schwachstellen veröffentlich werden ist es nur eine Frage der Zeit, bis der erste Angriff erfolgt. Doch auch die Bekanntgabe von Sicherheitspatches ist ein Grund für Angreifer die dort beschriebenen Sicherheitslücken auszunutzen. Bedingt durch das Internet verbreitet sich das Wissen über existierende Sicherheitslücken sehr schnell. Die Zeitspanne zwischen dem Bekanntwerden der Lücken und den ersten Angriffen wird jährlich kürzer.[4] [5]
Im Ernstfall können diese Sicherheitslücken dann zu Umsatzeinbußen bis hin zum Verlust geistigen Eigentums führen.[6]
Es gibt bereits zahlreiche automatische Update Möglichkeiten, welche im AntiViren-Bereich schon lange Standard geworden sind. Vielfach wird es aber dem Benutzer überlassen, die Patches manuell zu installieren, um ihr System auf einem sicheren Stand zu halten. Gerne und oft wird dies aber aufgeschoben, da die Auswirkungen häufig nicht bewusst sind.[7]
Um sicherzustellen, dass Systeme immer auf einem aktuellen und sicheren Stand sind, sollte jedes Unternehmen einen Prozess für das Patch-Management haben. Dieser Prozess sollte garantieren, dass alle Systeme immer aktuell sind und die neuesten Patches enthalten. Organisatorisch sowie technisch muss hierfür eine Richtlinie festgelegt werden.[8]
Dieser Prozess wird als Patch-Management bezeichnet, welcher auch im Change-Management häufig Anwendung findet. Das folgende Kapitel soll das Change-Management beschreiben und den Zusammenhang zwischen diesen beiden Management Bereichen verdeutlichen.
2.2 Einordnung in das Change-Management
„Change-Management bedeutet ganz generell […]: das Management von Veränderung beziehungsweise den Wandel gestalten.“[9]
Change-Management ist ein englischer Begriff und steht für Veränderungs- oder Transformationsmanagement. Es beschreibt den Umgang mit externen sowie mit internen Veränderungen mit denen ein Unternehmen umgehen muss. Seine historisch geprägten Ursprünge kommen aus den 50er Jahren des letzten Jahrhunderts. Lange Zeit waren Unternehmen stark hierarchisch organisiert. Jeder Mitarbeiter hatte klare Aufgaben und die Organisation mit den damit verbundenen Autoritäten wurde stets akzeptiert. Mit der Zeit kam allerdings der Wunsch auf, sich stärker an den Mitarbeitern zu orientieren. Veränderungen wurden nun nicht mehr nur von oben bestimmt, sondern mussten über Prozesse mit den Mitarbeitern abgesprochen und vereinbart werden. Change-Management ist die Strategie des geplanten und systematischen Wandels unter möglichst starker Beteiligung der betroffenen Bereiche bzw. Arbeitnehmer.[10] [11]
Mit Hilfe des Change-Managements soll der optimale Prozess entwickelt werden, um vom Ausgangspunkt zum Ziel zu kommen. Dazu gehört aber nicht die inhaltliche Definition des Zieles oder die Entwicklung von Methoden, sondern viel mehr die Gestaltung des Weges zum Ziel. Es beschreibt die Maßnahmen, welche sicherstellen, dass neuartige Strategien oder Strukturen initiiert und in der Zukunft umgesetzt werden können.[12] [13]
„Change-Management ist somit ein Meta-Begriff, der einzelne Konzepte subsumiert, die sich durchaus ergänzen oder auch widersprechen können“[14]
Der Patch-Management-Prozess, auf welchen im folgenden Kapital näher eingegangen wird, kann als ein Teilkonzept des Change-Managements angesehen werden. Dieser Prozess ist ähnlich strukturiert wie der Change-Management-Prozess nach der IT Infrastructure Library (ITIL). ITIL ist eine Zusammenstellung von herstellerunabhängigen „Best-Practices“-Methoden, die aus der Praxis gewonnene Erfahrungen und Erkenntnisse beschreibt und als Richtlinie zum systematischen Aufbau einer professionellen IT Servicestruktur bereitstellt.[15]
Die folgende Grafik veranschaulicht die Aufgaben des Prozesses im Change-Management nach ITIL:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Aufgaben des Change-Management-Prozesses
Quelle: Eigene Darstellung in Anlehnung an Victor, F. et al. (2005), S. 57ff.
2.3 Der Patch-Management-Prozess
Durch den Prozess der Updateverwaltung werden neue oder verbesserte Softwareversionen in der Produktionsumgebung bereitgestellt und gewartet. Mit diesem Prozess sollen Betriebsabläufe effektiv unterstützt, Sicherheitslücken geschlossen und die Stabilität der produktiven Umgebung gewährleistet werden.[16]
Die nachstehende Grafik veranschaulicht den Vierphasenansatz, der den Patch-Management-Prozess darstellt:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Vierphasenansatz des Patch-Management-Prozesses
Quelle: Eigene Darstellung in Anlehnung an Trent, R. (2006), S. 26f.
Dieser Prozess wird immer wiederholt, auch wenn keine neuen Updates verfügbar sind, denn die Vorbereitung für zukünftige Updates ist ein immer anstehender Prozess. Im Folgenden sollen die vier Phasen näher beschrieben werden.
Assess (Bewerten): Der Vierphasenansatz beginnt mit einer Bewertung der Gegebenheiten die in der Produktionsumgebung vorliegen. Mögliche Sicherheitslücken sowie Bedrohungen müssen erkannt und gewichtet werden. Auch die Frage, ob das Unternehmen auf Sicherheitsupdates vorbereitet ist, muss geklärt werden. Hilfreich hierfür ist es, alle Informationen über die Umgebung mit Hilfe eines Inventur-Mechanismus zu erfassen. Außerdem müssen die Quellen für Informationen über Softwareupdates von vornherein evaluiert und festgelegt werden. Eine automatische Benachrichtigung über E-Mail kann von besonderem Vorteil sein. Das Wissen, wie eine Installation von Softwareupdates abläuft, muss vermittelt werden. Mit allen gesammelten Informationen ist es dann möglich, eine Richtlinie für kommende Softwareupdates zu erstellen. Diese Richtlinie muss natürlich bei einer Veränderung der IT-Struktur oder bei Softwareveränderungen aktualisiert und gepflegt werden.[17]
Identify (Bestimmen): Diese Phase setzt sich das Ziel, Updates zu erkennen und zu überprüfen, ob diese für die Produktionsumgebung relevant sind. Wenn ein Update zur Verfügung steht muss entschieden werden, ob das Update normal installiert werden soll oder ob es sich um einen akuten Notfall handelt, der sofort einen Eingriff mit sich bringt. Wenn diese Klassifizierung erfolgt ist, können die benötigten Updates heruntergeladen werden und erstmals vorab getestet werden. Hierbei wird überprüft, ob sich das Update nach Updateanleitung erfolgreich installieren und deinstallieren lässt. Wenn die nächste Phase von anderen Mitarbeitern durchgeführt wird, kann eine Dokumentation der erworbenen Kenntnisse sinnvoll sein. Gerade hinsichtlich des Change-Managements sollte eine Dokumentation immer durchgeführt werden.17
Evaluate and Plan (Evaluieren und Planen): Ob ein bestimmtes Update durchgeführt wird oder nicht, wird in dieser Phase entschieden. Nach dieser Entscheidung muss festgelegt werden, mit welcher Wichtigkeit das Update installiert werden muss. Hierfür wird eine Klassifizierung vorgenommen, die dies eindeutig kennzeichnet. Zu dieser Phase gehört ebenso ein ausführlicher Test in einer produktionsnahen Umgebung um sicherzustellen, dass andere Systeme oder Anwendungen nicht von diesem Update beeinträchtigt werden. Die Dauer dieser Tests richtet sich nach der zuvor erfolgten Klassifikation. Ist ein Patch zum Beispiel als „ Critical “ eingestuft und muss dann laut vorher festgelegten Richtlinien innerhalb von 24 Stunden eingespielt werden, fällt die Testphase dementsprechend kurz aus. Nach den Tests muss sowohl ein Plan erstellt werden, wie das Update in der Produktionsumgebung installiert wird, als auch ein Plan, wie das Update im Fehlerfall wieder Rückgängig gemacht werden kann. Eine ausführliche Dokumentation dieser Pläne sollte am Ende dieser Phase vorliegen.17
Deploy (Bereitstellen): Die letzte Phase hat das Ziel, die Softwareupdates in der Produktionsumgebung erfolgreich zu installieren. Hierzu gehören zum Einen die Vorbereitung und zum Anderen die Ausführung auf den Zielrechnern. Wichtig ist, alle relevanten Personen von dem Update im Voraus in Kenntnis zu setzen und sowohl klare Informationen wann und wie das Update installiert wird, als auch die Wichtigkeit des Updates zu kommunizieren. Während der Installation muss ständig überwacht werden, ob das Update wie geplant installiert wird um notfalls fehlerhafte Schritte nach Plan rückgängig zu machen. Als letztes sollten die Erkenntnisse dieses Prozesses gesammelt, diskutiert und dokumentiert werden. Diese Erkenntnisse laufen wiederum in die erste Phase „ Assess” ein, um das nächste Update noch reibungsloser installieren zu können und um die im folgenden Kapitel beschriebenen Herausforderungen zu umgehen.17
2.4 Herausforderungen beim Patch-Management
Die meisten Benutzer setzen heutzutage viele verschiedene Produkte ein. Den Überblick über den Softwarestand und über die vielen Updates zu behalten ist daher oft schwierig.[18]
Wie in Kapitel 2.1 festgestellt, wird die Zeitspanne zwischen dem Erkennen einer Sicherheitslücke und den daraus resultierenden ersten Angriffen immer geringer. Daher sollten Updates innerhalb weniger Tage schnell verteilt werden. Dies ist oft eine große Herausforderung.[19]
Das Installieren von Patches nach dem zuvor beschriebenen Patch-Management-Prozess ist sehr arbeitsintensiv und auch zeitaufwändig. Neue Patches erscheinen bei einigen Produkten sogar im Wochenrhythmus und viele Unternehmen können die für die Installation erforderlichen Ressourcen nicht bereitstellen. Auch wenn ein Patch kostenlos ist, sind die damit verbundenen Personalkosten nicht zu missachten. Zusätzlich ist nicht immer eindeutig, ob die beschriebene Sicherheitslücke für bestimmte Unternehmen relevant ist und daher wird meist zur Installation aller verfügbaren Updates geraten. Der dafür bereitgestellte automatische Installationsprozess ist jedoch oft kaum transparent und es wird nicht ersichtlich ob oder welche Daten dabei eventuell an den Hersteller übermittelt werden.[20]
[...]
[1] Fiktiver Unternehmensname, vom Autor erfunden.
[2] Vgl. Trent, R. (2006), S. 1.
[3] Vgl. Bundesamt für Sicherheit in der Informationstechnik (2010), https://www.bsi-fuer-buerger.de/
[4] Vgl. Zehner, M. (2007), S. 137.
[5] Vgl. Aebi, D. (2004), S. 62.
[6] Vgl. Microsoft (2007), http://www.microsoft.com/.
[7] Vgl. Bundesamt für Sicherheit in der Informationstechnik (2010), https://www.bsi-fuer-buerger.de/
[8] Vgl. Aebi, D. (2004), S. 63.
[9] Doppler, K. (2003), S. 9.
[10] Vgl. Winter, W. et al. (2004), S. 7.
[11] Vgl. Kraus, G. et al. (2006), S. 14f.
[12] Vgl. Lauer, T. (2010), S. 3f.
[13] Vgl. Gattermeyer, W. (2001), S. 14.
[14] Kraus G. et al. (2006), S. 14.
[15] Vgl. Olbrich, A. (2008), S. 51.
[16] Vgl. Microsoft (2007), http://www.microsoft.com/.
[17] Vgl. Trent, R. (2006), S. 26ff.
[18] Vgl. Bundesamt für Sicherheit in der Informationstechnik (2010), https://www.bsi-fuer-buerger.de/
[19] Vgl. Zehner, M. (2007), S. 137.
[20] Vgl. Aebi, D. (2004), S. 62f.
- Quote paper
- Thomas Beer (Author), 2011, Patch-Management, Munich, GRIN Verlag, https://www.hausarbeiten.de/document/179196
