Die Verteilung und die Installation von Patches für Software gehören zu den wichtigsten Aufgaben, die dem IT-Team eines Unternehmens übertragen werden.
Es gibt zahlreiche Tools, die für die Bewältigung dieser Aufgaben konzipiert sind, welche unter dem Oberbegriff „ “ (Softwareverwaltung) zusammengefasst werden:.
Was jedoch oft übersehen wird, ist, dass – unabhängig davon, welche Tools die IT für diese Aufgabe wählt – zunächst Prozess- und Richtlinienfragen geklärt werden müssen, bevor ein Unternehmen wirklich die Kontrolle über seine Softwareumgebung erlangen kann.
Zudem haben viele Unternehmen ihre Vorgehensweise beim Softwaremanagement seit den frühen 2000ser-Jahren nicht geändert. In diesem Blog gehe ich auf einige dieser prozessbezogenen Aspekte ein und erläutere deren Bedeutung.
Checkliste: Wichtige moderne Methoden des Softwaremanagements
Eine zentralisierte Softwarebereitstellung und -aktualisierung sind am effektivsten
Meiner Erfahrung nach weisen Unternehmen, die ein dezentrales Modell für das Software-Management einsetzen, eine deutlich schlechtere Sicherheitspraxis auf als Unternehmen, die ein zentrales Modell nutzen.
Und mit „zentralisiert“ meine ich, dass eine Organisation zwar über dezentralisierte Support-Mitarbeiter verfügen kann, es jedoch eine zentrale Instanz gibt, die festlegt, welche Software und welche Software-Updates wann installiert werden. Die dezentralen Support-Teams richten sich alle nach diesem Rhythmus.
Die Zentralisierung fördert die Geschwindigkeit bei Tests und Patches
Einer der wichtigsten Aspekte des Softwaremanagements ist die Geschwindigkeit bei Tests und der Installation von Patches. Bei der Umstellung auf ein zentralisiertes Modell sollten Sie eine schrittweise oder stufenweise Einführung vornehmen. Bevor Sie die Änderung in die Produktionsumgebung übernehmen, sollten Sie einige Testphasen durchführen. „Ein paar“ bedeutet zwei oder drei, nicht 20!
Der Punkt ist, dass Sie nicht möchten, dass Ihre Endgeräte zu lange anfällig sind; daher sollten Sie diese Updates so schnell wie möglich bereitstellen. Im Allgemeinen sind 7-15 Tage ein realistisches Ziel; je nach Dringlichkeit des Updates kann dieser Zeitraum jedoch auch kürzer ausfallen.
Das ist die strategische Seite des Softwaremanagements. Legen Sie Service-Level-Vereinbarungen (SLAs) für Ihre wichtigsten Patches fest. Stellen Sie sicher, dass der Wert so niedrig wie möglich ist. Legen Sie eine Zahl nicht auf der Grundlage dessen fest, was Sie in den vergangenen 20 Jahren getan haben. Setzen Sie sich ehrgeizige Ziele.
30 Tage sind eine lange Zeit
Wenn ich in ein Unternehmen komme und dessen Patch-Zyklus länger als 30 Tage ist, besteht der erste Schritt darin, diese Updates innerhalb von 30 Tagen bereitzustellen und auf allen Geräten zu installieren. Schlimmer als das dürfte es nicht sein.
Sie müssen sich darüber im Klaren sein, dass, sobald diese Updates veröffentlicht werden, auch die Kriminellen davon Kenntnis erhalten. Diejenigen, die in Ihre Systeme eindringen wollen, können die Dokumentation lesen; sie können sehen, was gepatcht wird und warum. Die Zeit läuft sofort, und Sie müssen Ihre Software aktualisieren, bevor Sicherheitslücken ausgenutzt werden. Deshalb sage ich, dass 30 Tage eine lange Zeit sind.
Nun möchten Sie Patches möglicherweise nicht immer sofort auf Ihren Produktionssystemen installieren. Möglicherweise haben Sie Probleme mit internen Anwendungsabhängigkeiten. Beispielsweise kann es vorkommen, dass .NET-Patches nicht reibungslos mit einer Ihrer selbst entwickelten Anwendungen zusammenarbeiten. Diese Dinge werden eintreten.
In der Regel steht Ihnen ein Zeitraum von etwa einer Woche zur Verfügung, in dem Sie diese Konflikte überprüfen können. Und letztendlich möchten Sie diese 30 Tage so weit wie möglich auf eine Woche verkürzen. Das sollte das Ziel sein.
Wie schlimm ist es denn nun wirklich? Die Welt des „Catchup-Patching“
Was mir im Laufe der Jahre besonders deutlich geworden ist, ist, wie viele Unternehmen der Meinung sind, dass sie hervorragend oder zumindest nicht schlecht abschneiden. Sie geben sich selbst die Note „B+“.
Doch dann führen wir eine Überprüfung durch und entdecken Tausende kritischer Patches, die bis ins Jahr 2007 zurückreichen. Offensichtlich funktioniert etwas nicht. In der Regel handelt es sich um eine Kombination aus Werkzeugen und Prozessen. Beide Aspekte müssen berücksichtigt werden.
Für viele Unternehmen entspricht die von ihnen heute angewandte „ “-Patching-Methodik noch immer derjenigen aus den Jahren 2007 oder 2010. Doch die Welt, in der sie agieren, hat sich verändert. Es fehlen ihnen Patches aus einem Zeitraum von einem Jahrzehnt oder mehr, unabhängig davon, ob sie davon wussten oder nicht.
Es ist nicht ungewöhnlich, zunächst mit kritischen und wichtigen Sicherheitsupdates für Ihre Betriebssysteme zu beginnen. All diesen Updates sind Schweregrade zugeordnet, sodass Sie anhand dieser einen Eindruck davon gewinnen können, wie anfällig Ihre Betriebssysteme sind.
Es gibt zudem Schweregrade im Zusammenhang mit Updates von Drittanbieteranwendungen unter , wie beispielsweise Adobe Acrobat (siehe unseren Blogbeitrag zum Ende der Lebensdauer (EOL) von Adobe Flash unter ), Webbrowser wie Chrome und Firefox sowie Produktivitätsanwendungen wie Office365.
Beginnen Sie beim „Nachhol-Patching“ mit den kritischsten und wichtigsten Updates. In einer verteilten Umgebung erzielen Sie damit das beste Preis-Leistungs-Verhältnis, doch geben Sie sich damit nicht zufrieden.
Die technische Bewertung von Mängeln im Software-Management ist einfach – deren Behebung hingegen nicht
Es dauert nicht lange, bis sich Lücken in den Methoden zur Softwareverteilung und -aktualisierung erkennen lassen. Es kann jedoch zeitaufwendig und umstritten sein, einen Konsens über die Strategien und Verfahren zu erzielen, mit denen diese Lücken geschlossen werden sollen.
Menschen bauen ihre Karriere darauf auf, Dinge auf eine bestimmte Art und Weise zu tun, und oft möchten sie sich nicht ändern. In vielen Fällen wird ihnen erst dann bewusst, dass der einzige Grund für das Bestehen dieser Richtlinien darin liegt, dass „wir es schon immer so gemacht haben“, wenn sie beginnen, diese Richtlinien tatsächlich zu hinterfragen und zu überdenken. Einer der Bereiche, in denen Sie wahrscheinlich auf den größten Widerstand stoßen werden, sind Systemneustarts nach einem Update.
Das liegt daran, dass ein Neustart des Systems Auswirkungen auf die Endnutzer hat. Es kann buchstäblich Monate dauern, bis Unternehmen entscheiden, wie Endgeräte neu gestartet werden sollen, und dabei eine angemessene Benachrichtigung gewährleisten – damit niemand neu gestartet wird, während er zum Mittagessen geht, mitten in einer Präsentation steht oder an einem wichtigen Dokument arbeitet.
Hier ist eine starke Führung auf Führungsebene unerlässlich, um die Neustart-Richtlinie durchzusetzen, da – insbesondere in der Windows-Umgebung – ein Patch erst dann tatsächlich installiert und der anfällige Code ersetzt ist, wenn das System oder die Anwendung neu gestartet wird.
In einigen Organisationen wird es dem Endbenutzer überlassen, den Neustart durchzuführen, und es erfolgt keine Benachrichtigung darüber, dass ein Neustart erforderlich ist. Endnutzer werden sich an strengere Richtlinien anpassen, sofern diese durchgesetzt werden.
Sie werden lernen, das System bereits beim ersten oder zweiten Mal, wenn sie eine Benachrichtigung erhalten – vielleicht noch vor dem Mittagessen –, neu zu starten, anstatt immer wieder auf „Aufschieben“ zu klicken, bis der Neustart schließlich zu einem ungünstigen Zeitpunkt erzwungen wird.
Wenn wir gemeinsam mit einem Kunden an der Softwareverteilung arbeiten, ist einer der ersten Punkte, auf die wir achten, der letzte Neustart. Und oft stellen wir fest, dass 75 Prozent der Systeme in einem Unternehmen einen Neustart benötigen. Also, diese Patches, die Sie installiert haben? Das sind sie wirklich nicht.
Das Thema Risiko ist ein fester Bestandteil jeder Diskussion über Software-Patches
Der Hauptgrund, warum Unternehmen Patches nicht umgehend installieren, ist die Befürchtung, dass dabei etwas nicht mehr richtig funktioniert. Wenn ich mit Vizepräsidenten und Führungskräften der obersten Ebene über Software-Updates spreche, kommt in jedem Gespräch das Thema Risiko zur Sprache. „Wie hoch ist das Risiko, dass mein System 45 Tage lang anfällig ist, im Vergleich zu dem Risiko, dass ich nach 30 Tagen eine Änderung einführe und dadurch meine Anwendung unbrauchbar mache?“ Es ist die Angst vor dem Unbekannten. Es ist die Angst vor Betriebsstörungen.
Wenn Sie über einen Testplan und Kennzahlen verfügen, können Sie diese Befürchtung abbauen. Selbst wenn dieser Testplan lediglich lautet: „Lassen Sie uns dieses Update auf einer Reihe von Systemen bereitstellen und sehen, ob dabei etwas nicht mehr funktioniert.“ Aber Sie sollten erkennen können, ob etwas kaputt gegangen ist. Sie sollten über diese Daten verfügen und nicht darauf angewiesen sein, dass jemand ein Störungsmeldeticket eröffnet.
Wenn Anwendungsverantwortliche über konkrete Daten verfügen, die belegen, dass Patches sicher sind, werden sie eher bereit sein, zuzustimmen, wenn Sie ankündigen, Ihren Patch-Zyklus von 30 auf 15 Tage zu verkürzen.
Um einen Einblick zu erhalten, wie Tanium die Verwaltung von Drittanbietersoftware im Rahmen von „ “ vereinfacht, besuchen Sie bitte unbedingt „9 Wege, wie Tanium Ihnen die Kontrolle über Ihre Endgeräte-Softwareumgebung ermöglicht“.
Wenn Sie bereit sind, das Produkt in Aktion zu erleben, melden Sie sich noch heute unter für eine Demo an: .
