Der Weg zu erfolgreichem Patch-Management. Patch as Patch can?

Transkript

1 Der Weg zu erfolgreichem Patch- Patch as Patch can? Patch- ist und bleibt für Unternehmen ein heißes Thema: Oft überfordert die Verteilung von Security Patches die IT-Abteilung und beeinträchtigt den Betriebsablauf. Das Heil wird deshalb in der Einführung eines Patch-Verteilwerkzeuges gesucht meist ohne den gewünschten Erfolg. Dabei enthält der Begriff Patch- schon den Schlüssel des Problems: ist erforderlich IT

2 Werkzeuge für das Patch- allein reichen nicht aus, um Sicherheitslücken zu vermeiden und Angriffe schnell abwehren zu können sie decken nur etwa fünf Prozent eines Patch--Prozesses ab. Die Entwicklung eines strukturierten Ansatzes für den Patch-Roll-out im Rahmen der IT-Unternehmensstrategie dauert zwar zunächst weitaus länger und beinhaltet eine ganze Reihe wichtiger Schritte, macht sich aber letztendlich bezahlt. Dabei gilt es nicht nur technische Anforderungen zu erfüllen vielmehr sind in erster Linie fest definierte Prozesse und geschulte Mitarbeiter erforderlich. Das Sicherheitsproblem Die steigende Notwendigkeit von Patches ergibt sich aus einem Wandel in der modernen Informationstechnologie: Während der letzten 30 Jahre sind die Software-Systeme zunehmend komplex geworden die Wahrscheinlichkeit von Fehlern im Code und in der Konfiguration bezogen auf ihre Angreifbarkeit hat dramatisch zugenommen. Keine Software ist fehlerfrei. Außerdem fehlt für eine komplette Sicherheitsprüfung vor Auslieferung manchmal die Zeit; das Produkt und damit das Unternehmen, das es einsetzt wird angreifbar. Gleichzeitig stieg seit den 90er Jahren und der Verbreitung des Internets die Zahl von öffentlich angebundenen PCs kontinuierlich an. In diesen Zeiten von Internet, Memory-Sticks, CD- und DVD-Brennern kann sich ein Mitarbeiter theoretisch jede beliebige Software beschaffen und in vielen Unternehmen meist auch selbst installieren. Die zunehmende Integration der Infrastruktur, verbunden mit der hohen Komplexität vernetzter Systeme, überfordert viele Unternehmen dann in ihren Möglichkeiten zur Systempflege und Aktualisierung. Denn eine der Hauptaufgaben jeder IT-Abteilung besteht heute darin, die unternehmensweite Infrastruktur ständig zu überwachen, zum Schutz vor neuen Sicherheitsbedrohungen zu aktualisieren und eine mehrstufige Verteidigung zu installieren schließlich verfügen versierte Hacker über umfangreicheres und professionelleres Wissen als noch vor einigen Jahren und lassen sich von einem einzelnen Sicherheitsmechanismus allein nicht abhalten. Patch-: mehr als Rettung im letzten Moment Patch Prozessüberblick Setup Activities Initiation Release Baselining Subscription Identification Relevance Quarantine Request Classification Authorization Development Plan Release Release Development Acceptance Testing Roll-Out Planning Roll-Out Preparation Release Deployment Review Der Handlungsbedarf bei Patches ergibt sich aus einem akuten Leck im System, einer Gefahr für die (Daten- )Sicherheit eines Unternehmens. Oft ist das zu lösende Problem jedoch nur die Spitze des Sicherheits-Eisberges : Gemäß Untersuchungen von Gartner basieren nur 35 Prozent der Sicherman die typischen Aktivitäten eines Unternehmens in diesen vier Wochen, dann lässt sich feststellen, dass der weitaus größte Teil der verfügbaren Zeit mit dem Testen der Patches verbracht wird und nur der kleinste Teil mit deren eigentlicher Verteilung. Sucht man also nach einem Patch-Verteilwerkzeug, optimiert man damit zwar einen wichtigen, aber letztlich den Teil, der am wenigsten der Optimierung bedarf. Das weitaus größere Potenzial liegt dagegen in der Verbesserung der Aktivitäten vor der Verteilung. Leider sind viele Unternehmen hierfür nicht optimal aufgestellt: Bild 1: Erfolgreich implementiertes Patch- durch Einbettung in einen stringenten Prozess. heitsprobleme auf Defekten des Codes, dagegen 65 Prozent auf Fehlkonfigurationen des Systems es ist oft ungenügend abgesichert, schlecht konfiguriert und enthält unnötige Dienste. Ein weiteres Problem: Die verfügbare Reaktionszeit (Time to Respond, TTR) ist zu knapp, und viele Unternehmen können nicht innerhalb angemessener Zeiten auf einen Angriff reagieren. Tendenziell pendelt sich die Vorwarnzeit vom Bekanntwerden bis zum Ausbruch bei vier Wochen ein. Betrachtet Configuration (CMDB) Fehlende Information über aktuelle Systeme Im Falle eines Falles sollte sich schnell feststellen lassen, wie viele und welche Systeme von dem Problem überhaupt betroffen sein könnten. Hierzu gehört auch die Überwachung des Roll-out- Fortschrittes während des Deployments. Begrenzte Priorisierung von Systemen und Applikationen Welches sind die für ein Unternehmen wichtigen Systeme? Welches sind die IT

3 Verfügbare Reaktionszeit Time to Respond (TTR) H Awareness of vulnerability Bulletin and update availability Effort Systeme, die aus einer Sicherheitsbetrachtung heraus besondere Bedeutung haben? Diese Fragen werden häufig nicht gestellt geschweige denn beantwortet. Fehlende Standardisierung Das Grundübel schlechthin. Zwar helfen bereits das Festlegen von Betriebssystemversion und Hardware- Plattform sowie die Definition eines Standard-Software-Warenkorbes, sie sind aber nicht ausreichend. Ohne umfangreiche Betrachtung der Sicherheitseinstellungen und des Admin-Modells, Regeln zur Entwicklung interner Software, Definition von Paketierungsregeln und -formaten kommt man nicht ans Ziel. Mehrere Versionen von Betriebssystemen und Applikationen Ein Unterpunkt der Standardisierung. Häufig lässt sich das verwendete Software-Portfolio durch Konsolidierung gleichartiger Produkte deutlich einschränken. request approved Release Effort Ta Tb Tc Td Te Bild 2: Typische Aktivitätenverteilung in einem Patch-Roll-out Deployment confirmed Exploit in the wild Software update available Open Vulnerability Keine oder schlechte Testmöglichkeiten Müssen zu viele unterschiedliche Konfigurationen unterstützt werden, wird der Test eines Patches gegen alle anderen Applikationen unmöglich. Über den Ansatz der Standardisierung lässt sich dieser Aufwand bereits massiv reduzieren, er sollte jedoch begleitet sein von definierten und reproduzierbaren Testszenarien und weitestgehender Automatisierung. Fehlende automatische Softwareverteilung Kaum zu glauben, aber wahr: Viele Unternehmen verfügen heute noch über keine Infrastruktur, die Patches sicher und zuverlässig innerhalb von 24 Stunden auf alle Rechner installieren kann. Darüber hinaus existieren häufig Parallelinstallationen verschiedener Hersteller und unterschiedliche Installationsvarianten. Unzureichend definierte Prozesse Viele Unternehmen sind heute nicht genügend organisiert, um den Express-anforderungen eines - Prozesses für Patches gerecht zu werden. Diese Liste zeigt: Um die grundlegenden Probleme zu lösen, bedarf es weit mehr als der Einführung eines Tools. Standards und Prozesse sind vorausgesetzt Die meisten Unternehmen übersehen bei der Betrachtung des Patch-s die eigentlichen Ursachen des Problems: Es mangelt an Standards und Prozessen sowie deren Umsetzung. Hinzu kommt, dass Patch- als singuläre, auf die Verteilung von Fehlerbehandlungsroutinen reduzierte Tätigkeit betrachtet wird, anstatt als integrierter Bestandteil des gesamten Software-s. Ausreichender Schutz funktioniert nur über permanente und vor allem schnelle Aktualisierung aller betroffenen IT-Einrichtungen. Deshalb kommt heute kein Unternehmen ohne eine ganzheitliche Sicherheitsstrategie aus, in die neben der Technik auch die Prozesse und vor allem die Menschen eingebunden sind. Erst das Zusammenspiel dieser drei Komponenten gewährleistet den langfristig und nachhaltig sicheren Betrieb der gesamten Infrastruktur des Unternehmens. In besonderem Maße ist der Kommunikationsfluss zwischen den beteiligten Abteilungen zu optimieren schließlich sollten Softwareentwickler und/oder Fachabteilungen gemeinsam mit den Verantwortlichen für die Infrastruktur des Unternehmens das notwendige Prozedere definieren. Zwar findet meist eine Standardisierung rein auf Betriebssystemebene statt, beschränkt sich aber leider häufig auf eben genau diese und die Hardware-Plattform. Komplizierter wird das Thema in der Praxis bei den meist etwa 600 bis mehreren tausend in größeren Unternehmen eingesetzten Applikationen und der daraus resultierenden Vielzahl möglicher Sucht man also nach einem Patch-Verteilwerkzeug, optimiert man damit zwar einen wichtigen, aber letztlich den Teil, der am wenigsten der Optimierung bedarf IT

4 Schritte zu erfolgreichem Patch- 1. Bestand erfassen Die Erfassung des Softwarebestands ist die Grundlage, um die benötigten Patches identifizieren zu können. In größeren Unternehmen ist ein Tool-gestütztes Verfahren notwendig. Das Tool sollte auf jeden Fall detaillierte Softwareversionen erfassen können. Installationsroutinen sollten so angepasst werden, dass eine automatisierte Inventarisierung möglich ist (z.b. Hinzufügen von Registrierungseinträgen). 2. Profile definieren Nach Bestandserfassung können Profile definiert werden, z.b.: Standard-Client mit Windows XP Professional SP1 und Hotfix oder Web-Server mit Windows 2000 Server SP3 und IIS und Security Roll-Up Package. Profile entsprechen den standardisierten Systemtypen im Unternehmen Systeme, die vom definierten Standardprofil für diese Systemklasse abweichen, genauer untersuchen. 3. Informationen über neue Patches beschaffen -Benachrichtigungen Für Microsoft-Produkte kann unter eine -Benachrichtigung abonniert werden Andere Hersteller bieten oft ähnliche Dienste an Ein kostenloser allgemeiner Benachrichtigungsdienst in deutscher Sprache ist vom Computer Emergency Response Team der Uni Stuttgart verfügbar ( Information an zuständige Stellen kanalisieren 4. Patches klassifizieren und verifizieren Patches mit den im Unternehmen vorhandenen Plattformen abgleichen Mögliche Auswirkungen auf die Umgebung feststellen Risiko-Analyse Roll-out Kein Roll-out Patch und seine Quelle validieren Patches sind nie in s enthalten! Gibt es zu diesem Patch einen entsprechenden Knowledge- Base-Artikel des Herstellers? Ist der Patch digital signiert? Patch analysieren Welche Dateien werden verändert? Welche Auswirkungen lassen sich daraus ableiten? Ausführbare Dateien auf Viren überprüfen Roll-out-Entscheidung Weniger wichtige Patches sammeln und zu einem Roll-out bündeln. Bei kritischen Patches eine kurzfristige Besprechung mit den Spezialisten für die entsprechende Plattform einberufen. Beschleunigungsprozess für kritische Patches installieren. Entscheidung über Implementierung treffen 5. - Request (RFC) mit detaillierten Informationen eröffnen Mögliche Seiteneffekte Abhängigkeiten / Besonderheiten (z.b. Cluster) Priorität Benötigt der Patch einen Neustart? Anzahl der betroffenen Systeme ermitteln Patches folgen dem regulären --Prozess Wichtige Patches beschleunigt behandeln 6. Release- Grundlagen schaffen Release definieren Patches möglichst zusammenfassen Kritische von nicht-kritischen Patches trennen Wenn mehrere Patches einen Neustart erfordern, kann dies mit QChain auf einen Neustart für das Release reduziert werden Paketierung und anschließender Import in das Softwareverteilungswerkzeug je nach Umgebung Zielsysteme festlegen Integration der Softwareverteilung mit einer Configuration- Database (CMDB), in der zentral alle Konfigurationen hinterlegt sind, erleichtert die Auswahl der Zielsysteme 7. Release- Test und Rückfall-Szenario Testumgebung sollte Produktionsumgebung so weit wie möglich nachbilden Alle Systemprofile sollten in der Testumgebung vorhanden sein Testverfahren Sicherheitsrelevante Patches sollten nur minimale Tests erfordern Andere Patches längere Zeit in der Testumgebung belassen Umfangreiche Tests für Service Packs Backup Normale Backup- und Restore-Prozeduren müssen dokumentiert und getestet sein Bei Servern Vollsicherung vor Einspielen eines Patches durchführen 8. Release- Roll-out Geeignete Pilot-Systeme identifizieren Pilot-Systeme sollten repräsentativ sein Erfolgskontrolle durchführen Nach Kriterien klassifizieren Systeme in einer DMZ (Demilitarized zone; Netzwerk- Segment zwischen zwei Firewalls) Aus der DMZ erreichbare Systeme Server nach Rollen Applikations-Server Domänen-Controller Sonstige Server wie File- und Print-Server Clients Klassifizierung bildet die Grundlage für die Priorisierung von Patches Öffentlich zugängliche Systeme sollten so schnell wie möglich gepatcht werden Auch unkritische Systeme im Intranet sollten einen Mindestsicherheits-standard aufweisen, weil diese für Angriffe benutzt werden können Zielsysteme identifizieren und Patch verteilen Erfolgskontrolle Gegebenenfalls Fehler analysieren IT

5 Integriertes Softwaremanagement Priorität 1 in jedem Unternehmen Komplexes Szenario: Richtlinien und Standards Prozesse und Workflow Software-Entwicklung Packaging Patching Verschiedene Testszenarien Softwareverteilung und Roll-out Thin + Web Clients Automatisierung und User Self Anbindung und Unterstützung mobiler Geräte Vorteile: Automatische Inventarisierung des Hard- und Softwarebestandes Hilfe bei der Verteilung wichtiger Patches oder neuer Softwarebausteine Zeitersparnis in der Bestandsverwaltung der gesamten IT-Infrastruktur Kostenersparnis in der Beschaffung und Verwaltung der Systeme Besserer Auslastungsrad und höhere Verfügbarkeit der Endsysteme Integration der Produkte untereinander und mit dem Service Desk Informationsquelle für das Lizenz- Möglichkeit der Analyse und Wartung entfernt stehender Systeme Einhaltung von Richtlinien und Standardkonfigurationen Kontrollfunktion: Wo befindet sich das Gerät, wer ist der Nutzer, wie ist das System konfiguriert? zu Kostenreduktion im Unternehmen die Total Cost of Ownership je Desktop-Arbeitsplatz sinkt deutlich. Durch bessere Nutzung des vorhandenen Equipments sind pro eingesetztem PC jährlich Einsparungen von bis zu Euro möglich denn nicht die Anschaffung ist teuer, sondern der nicht optimierte Betrieb. Bei Anforderungen wie Hochverfügbarkeit und Kundenservice kostet jede Beeinträchtigung des Systems von der kurzen Störung bis hin zum Totalausfall Zeit, Geld und im schlimmsten Falle Kunden. Also heißt die Faustregel: Nicht an der falschen Stelle sparen, auch wenn die Security auf den ersten Blick für das Unternehmen keinen Profit erwirtschaftet, sondern in sinnvolles Software- investieren und bis zu 50 Prozent Kosten sparen. Neben der erreichten Sicherheit sollten Kostenkontrolle, steigende Rentabilität und Produktivität automatisch die Folge sein. Ullrich Stiens ullrich.stiens@avanade.com Kombinationen je Desktop ein ausreichender Test vor dem geplanten Patch-Roll-out ist nach herkömmlichen Methoden in dem zur Verfügung stehenden Zeitfenster meist nicht oder nur mit immensem Aufwand möglich. Deshalb ist es unabhängig von der eingesetzten Betriebssystem-Plattform notwendig, weit reichende Desktop- Standards zu implementieren um eine erfolgreiche Patch--Strategie zu realisieren. Eine solche Strategie beinhaltet den Bruch mit liebgewonnenen Gewohnheiten, denn Administratorenrechte für einzelne Benutzer, ad-hoc-installation von Software, die nicht den betrieblich festgelegten Standards entspricht, sonstige Insellösungen und private Downloads gefährden die Sicherheit des Gesamtbetriebs. Auch die Plug&Play- Mentalität und der Irrglaube vom je nach persönlichem Bedarf zu konfigurierenden Personal Computer lassen sich im Unternehmensumfeld nicht aufrechterhalten. Zu planbarem und damit dauerhaftem Erfolg benötigt man daher: Effektives Asset- Integriertes Software- Strikte Kontrolle von -Prozessen Hohen Grad von Standardisierung der Gesamtplattform Maßnahmen zur Kontrolle, Einhaltung und Wiederherstellung von Standards Umfassendes Sicherheitskonzept. Automatisierten Ablauf von Test, Update und Übergabe Und vor allem: Eine Unternehmenskultur, die einen kontinuierlichen Prozess der Optimierung unterstützt und den Sicherheitsgedanken konsequent umsetzt. Fazit Das sichere System per se gibt es nicht schließlich ist in der heutigen Zeit des Internets quasi jeder Rechner Teil des Netzes und damit angreifbar. So muss die Sicherheit eines Systems vielmehr integriert betrachtet und als dynamischer Prozess verstanden werden, der kontinuierliche Überwachung, regelmäßige Sicherheits-Updates und sicherheitsrelevante Konfigurationen verlangt. Diese integrierte Betrachtungsweise führt neben steigender Sicherheit auch Patch- wird fälschlicherweise oft als singuläre, auf die Verteilung von Fehlerbehandlungsroutinen reduzierte Tätigkeit betrachtet, anstatt als integrierter Bestandteil des gesamten Software- s IT