Patchmanagement im BIT Fast rollout vs. detailed testing

Transkript

1 Patchmanagement im BIT Fast rollout vs. detailed testing Reto Inversini :: 29. Mai 2006

2 Inhalt Motivation zum Patching Patchmanagement Ausgangslage, Projekt und Prozesse Patchmanagement der Alltag Blick in die Zukunft / CVSS Erfahrungen und Ratschläge Fragen und Diskussion 2

3 Wieso Patchen? das System läuft ja

4 4

5 Motivation Auch das BIT wurde in der Vergangenheit von Wurminfektionen nicht verschont. Die letzte grössere Infektion mit mehr als 10 Geräten wurde im August 2003 durch den W32.Blaster Wurm verursacht. Eine zweite Bedrohung ist der Angriff durch Skript Kiddies und schlimmer durch professionelle Hacker. Webserver gehören momentan zu den am stärksten gefährdeten Systemen und brauchen dementsprechend viel Aufmerksamkeit beim Patching. Patches braucht es nicht nur auf Systemebene, sondern ebenso auf Applikationsebene. 5

6 Motivation (2) Das Risiko ist die Bewertung der Eintretenswahrscheinlichkeit und der Auswirkung auf eine Ressource. Das Einspielen eines Patches beseitigt eine Schwachstelle und mindert damit die Gefährdung und senkt im Endeffekt das Risiko. 6

7 Risikobewertung ohne Patching 1. Epidemische Infektion durch Malware. 2. Einzelinfektionen durch Malware. 3. Gezielte Infektion einzelner Geräte durch Malware. 4. Erfolgreicher Hacker Angriff auf Systeme in der DMZ. 5. Erfolgreicher Hacker Angriff auf Systeme in den inneren Netzzonen. 6. Distributed Denial of Service. 7. Privilege Escalation durch lokale Benutzer. 8. Fremdgefährdung anderer, nicht dem Bund unterstehender Systeme. 7

8 Risikobewertung mit Patching 1. Epidemische Infektion durch Malware. 2. Einzelinfektionen durch Malware. 3. Gezielte Infektion einzelner Geräte durch Malware. 4. Erfolgreicher Hacker Angriff auf Systeme in der DMZ. 5. Erfolgreicher Hacker Angriff auf Systeme in den inneren Netzzonen. 6. Distributed Denial of Service. 7. Privilege Escalation durch lokale Benutzer. 8. Fremdgefährdung anderer, nicht dem Bund unterstehender Systeme. 8

9 Patching senkt das Risiko Das Einspielen von Patches reduziert in den aufgeführten Szenarien nicht die Auswirkung, aber die Eintretenswahrscheinlichkeit. Einzelne Szenarien können eine Firma an den Rand des Ruins führen (z.b. ein Hacker Angriff auf interne Systeme oder eine Wurminfektion epidemischen Ausmasses). Auch für das BIT gibt es Szenarien, von deren Folgen wir uns nur schwer und mit sehr grossem Aufwand erholen könnten. Ein konkretes Szenario ist ein Oracle Wurm, welcher eine der diversen Lücken in Oracle ausnützt und Datenbanken löscht oder modizifiziert. Patches einzuspielen gehört zur normalen Maintenance eines Systems und muss die Regel sein. 9

10 Patchmanagement Ausgangslage, Projekt und Prozessdefinitionen

11 Ausgangslage 2004 Das BIT verwaltet knapp W2k / W2k3 Server, sowie knapp 7000 W2k und XP Clients. Im Unixbereich sind es knapp Systeme. Die Bereitstellung und der Betrieb ist auf verschiedene Bereiche verteilt. Einzelne Bereiche (Betrieb AD Root, Büroautomationsserver, verwaltete Clients) hatten bereits mehr oder weniger etablierte Patchprozesse. Patches wurden jedoch nicht nach Risiko priorisiert, sondern nach Gutdünken und momentaner Arbeitslast eingespielt. Andere Bereiche hatten weder ein Patchmanagement noch wurden Patches eingespielt. Es gab im BIT keine Bereichsübergreifende Koordination. 11

12 Das Projekt Folgende Punkte waren für den Erfolg des Projekts kritisch: Unterstützung der Geschäftsleitung: Der ISBO des BIT startete das Kickoff Meeting der Bereichsleitern mit folgenden Worten: Das oberste Ziel ist es, Infektionen zu vermeiden und Betriebsunterbrüche zu minimieren. Die Definition der nötigen Prozesse und die Etablierung dieser Prozesse in einer Matrix. Das Vorhandensein von unterstützenden Tools. Die Awareness auf Seiten der Administratoren und der Kunden. Das Projekt arbeitete eine kurzfristig realisierbare und eine mittelfristig anzustrebende Variante aus. Zuerst wurde das Patchmanagement im Windows Bereich etabliert, danach im Unixbereich. 12

13 MOF / Patchmanagement Das Patchmanagement im MOF (Microsoft Operations Framework) ist im Changing Quadranten anzusiedeln, das Security Management mit der Untergruppe Riskmanagement gehört in den Optimizing Quadranten. Risk Management Patchmanagement 13

14 Prozessempfehlungen von MS Der Prozess von der Beurteilung bis zur Implementation ist wie folgt definiert: 1. Assess 2. Identify 4. Deploy 3. Evaluate & Plan Wir nahmen diesen Prozess und bildeten ihn auf unsere Organisationseinheiten ab. 14

15 Ablaufdiagramm Variante 1 Neuer Patch Beurteilung Entscheidung Test Packetierung Verteilung Gremium Security Gruppe BZxy1 BZxy1 BZxy1 BZxy1 BZxy2 BZxy2 BZxy2 New Patch Security Gruppe BZxy2 BZxy3 BZxy3 BZxy3 BZxy3 BZxyx BZxyx BZxyx BZxyx 15

16 Variante 1 (kurzfristig) Schaffung eines zentralen Gremiums: Beurteilt Relevanz eines Patches. Entscheidet über nötige Installationen. Legt Deadline der Installation fest. Verbleibende dezentrale Tätigkeiten im Bereich: Monitoring, Reporting. Testen, Paketieren und Installieren von Patches. Einbezug weiterer Prozesse (Changemanagement). 16

17 Ablaufdiagramm (mittelfristig) Neuer Patch Beurteilung Entscheidung Test Packetierung Verteilung Sec. Gruppe Sec. Gruppe New IOS Patch Spezialist Security Gruppe Spezialist Security Gruppe BZxy1 BZxy1 New MS Patch Spezialist Security Gruppe Spezialist Security Gruppe BZxy2 BZxy2 Leiter Security Gruppe New Linux Patch Spezialist Security Gruppe Spezialist Security Gruppe BZxy3 BZxy3 New AIX Patch Spezialist Security Gruppe Spezialist Security Gruppe BZxyx BZxyx 17

18 Variante 2 (mittelfristig) Schaffung eines zentralen Gremiums: Bildung einer im BZ integrierten OE. Betreuung von anderen Technologien im Bereich Patchmanagement (Unix, Cisco OS, Firewalls, usw.). Wahrnehmung von weitern betrieblichen (operativen) Aufgaben im Bereich Sicherheit innerhalb des BZ. Verbleibende dezentrale Tätigkeiten im Bereich: Monitoring, Reporting. Paketieren und Installieren von Patches. 18

19 Momentaner Stand im BIT Zwischenschritt zwischen der kurzfristigen Variante und der mittelfristigen. Die Patches werden von der Security Gruppe analysiert und klassiert. Es gibt eine zusätzliche Stelle, welche sich um den Stand des Einspielens von Patches kümmert. Die Tests der Patches werden jedoch nach wie vor innerhalb der Bereiche gemacht. Sowohl im Windows, wie auch im Unixbereich gibt es nun etablierte Prozesse zum Patchmanagement. 19

20 Patchmanagement der Alltag 1. Assess 2. Identify 4. Deploy 3. Evaluate & Plan

21 Patches und Service Packs Patch: Behebt eine Sicherheitslücke (oder sonst eine gravierende Fehlfunktion). Sollte in der Regel keinen Einfluss auf die Funktionalität haben. Service Packs: Beinhalten einerseits die über einen bestimmten Zeitraum aufgelaufenen Patches und erweitern und/oder verändern die Funktionalität. Wir behandeln Service Packs wie Betriebssystem Upgrades. Die Bereiche testen Service Packs selbstständig. Die Security Gruppe kann ein Service Pack als verpflichtend erklären. Das Einspielen von Service Packs muss vom Change Board für jedes einzelne System genehmigt werden. 21

22 Beurteilung eines Patches Der Bereich Sicherheit und Architektur macht ein Monitoring von neuen Vulnerability und Patch Meldungen. Dies betrifft sowohl die Microsoft, wie auch die verschiedenen Unix Plattformen. Jede Vulnerability wird nach folgenden Kriterien beurteilt: Betrifft sie unsere Systeme? Ist sie von Remote ausnutzbar? Was sind mögliche Angriffsszenarien? Existieren bereits öffentlich verfügbare Exploits? Gibt es mildernde Massnahmen? Auf der Basis dieser Beurteilung wird eine maximale Zeitdauer festgelegt, bis zu der die Patches auf allen Systemen eingespielt sein müssen. 22

23 Beurteilung eines Microsoft Patches Wir referenzieren die MS Bulletin Nummer, die KB Nummer, sowie die CVE (Common Vulnerability and Exploits Nummer). Bezüglich der Kritikalität verwenden wir folgende Stufen: kritisch, hoch, mittel, tief. 23

24 Vorlage für Vulnerability-Reports Produkt Version/Plattform Kurzbeschrieb CVE-Nummer(n) Detaillierte Beschreibung Flags: z.b. Ja Nein Nicht Relevant Referenz(en) zu Herstellerinfo(s) nd? Workarou Remote? Patch? Exploit? CVSS-Score CERT Risk TKOSI Termin 24

25 Beispiel im Bereich Unix Hewlett Packard Company HP-UX B.11.23, B.11.11, B HP-UX Usermod Unauthorized Access CVE A vulnerability has been reported in the 'usermod' command when handling the '-u' and '-m' commandline options, which could let a malicious user obtain unauthorized access. HP Security Bulletin, HPSBUX02102, March 17, 2006 N N J N 4.9 Mittel

26 Beurteilung eines Patches Es gibt folgende Szenarien, bei denen wir die Kritikalität eines Patches in der Regel herunterstufen: Kein direkter Angriffspfad: Firewall Regeln verbieten das für den Angriff verwendete Protokoll. Nicht zugelassene Filetypen ( /web): Bedroht die Vulnerability gewisse Filetypen, welche sowohl auf den Messaging Gateways und Proxyservern, wie auch auf den internen Exchangeservern blockiert werden, kann der Patch heruntergestuft werden. Durch GPOs oder lokale Security Einstellungen ausschaltbare und für das BIT verzichtbare Funktionalitäten. Wird eine Lücke bereits aktiv ausgenützt, erhöhen wir die Kritikalität. 26

27 Freigabe und Implementation Der Patchmanager (Mitglied der Security Gruppe) beurteilt die Patches und empfiehlt eine maximale Zeitspanne bis der Patch eingespielt sein muss. Dies wird anlässlich eines monatlichen Patchmeetings diskutiert und eine Entscheidung über die Implementation getroffen. Jeder Bereich führt in Eigenregie die nötigen Tests durch und meldet allfällige Probleme dem Patchmanager. Dieser führt eine Liste über Probleme und informiert nötigenfalls die anderen Bereiche. Nach Abschluss der Tests werden die Patches mit den jeweiligen Tools verteilt. 27

28 Technische Hilfsmittel Es werden verschiedene Hilfsmittel für die Ausbringung von Patches verwendet. Im Bereich Unix wird ein grosser Teil noch von Hand erledigt. Auf den Windows Plattformen sind momentan Shavlik HF Netcheck Pro, Columbus und WSUS im Einsatz. Das Tool von Shavlik erlaubt es, auch nicht-microsoft Produkte zu patchen. WSUS hat sich vor allem in Bereichen bewährt, welche ausschliesslich MS Produkte verwenden. Es wird im Umfeld des AD, der Exchange Server und von unmanaged Clients eingesetzt. Shavlik wird im Bereich Windows Applikations Server verwendet. Columbus kommt im Bereich Managed Clients zum Einsatz. 28

29 Shavlik HF Netcheck Pro 29

30 WSUS 30

31 Linux / Unix 31

32 Qualitätssicherung Das erfolgreiche Einspielen der Patches wird auf folgende Art und Weise kontrolliert: Die einzelnen Microsoft Bereiche überprüfen die Systeme mit Hilfe des MBSA (Microsoft Baseline Security Analyzer). Unter Unix werden die entsprechenden Commandline Tools verwendet. Dieser Test wird durch die Security Gruppe stichprobenartig wiederholt. Mit Hilfe von Nessus (Vulnerability Assessment Tool) werden Netzzonen summarisch auf extern erreichbare Vulnerabilities überprüft. Jeder Bereich hat einen Patchmanager, der für die Umsetzung der Vorgaben bezüglich Patches verantwortlich ist. 32

33 Qualitätssicherung mit MBSA 33

34 Qualitätssicherung mit Nessus 34

35 Blick in die Zukunft

36 Blick in die Zukunft Das verfügbare Fenster zum Testen wird immer kleiner. Die Komplexität der Applikationen nimmt zu. Anstelle von Massenwürmern werden die Angriffe immer gezielter und sind schwieriger zu entdecken. Defacements werden automatisiert durchgeführt. Es stehen vermehrt monetäre Interessen hinter den Angriffen. Die Angreifer arbeiten immer stärker arbeitsteilig und erreichen somit einen hohen Spezialisierungsgrad. Die Herausforderungen an ein gutes Patchmanagement sind weiter am Zunehmen. 36

37 Beurteilung der Patches mit CVSS Common Vulnerability Scoring System. Initiative des US-CERT zur Vereinheitlichung der Bewertung von Vulnerabilities. Fixe Kriterien nach welcher Vulnerabilities klassiert werden. Berücksichtigt werden 3 Gruppen von Kriterien: statische, d.h. einmal durch Hersteller gesetzte. zeitlich veränderliche, durch CERT täglich angepasste. umgebungsspezifische, durch Enduser (Organisation) vorgegebene und angepasste Parameter. 37

38 Beurteilung der Patches mit CVSS 38

39 Beurteilung der Patches mit CVSS Gruppe der Basiskriterien: Angriffsvektor: lokal oder remote. Komplexität für Angriff: Hoch oder Tief. Authentifizierung: nötig oder nicht nötig. Auswirkungen: Verlust der Vertraulichkeit: keiner, teilweise oder komplett. Verlust der Integrität: keiner, teilweise oder komplett. Verlust der Verfügbarkeit: keiner, teilweise oder komplett. Gewichtung der Auswirkungen: Normal, Vertraulichkeit, Integrität oder Verfügbarkeit. 39

40 Beurteilung der Patches mit CVSS Gruppe der zeitlichen Kriterien: Ausnützbarkeit: unbewiesen, beispielhaft, funktioniert oder hoch. Behebungsmöglichkeiten: offizieller Fix, temporärer Fix, Workaround oder nicht vorhanden. Vertrauen in die Meldung: unsicher, unbestätigt und bestätigt. Gruppe der Umgebungskriterien: Schadenspotential: kein, tief, mittel oder hoch. Anzahl der Ziele: keine, tief, mittel oder hoch. 40

41 Beurteilung der Patches mit CVSS 41

42 Beurteilung der Patches mit CVSS Alle neuen CERT-Advisories werden ab 2006 so bewertet. Der Wertebereich reicht von Auf die alte Skale übertragen bedeuten die Werte: Low Medium High 7 10 Das US CERT liefert die gewichteten Vulnerabilities tagesaktuell in Form eines RSS Feeds. Es ist möglich, den Feed automatisiert zu verarbeiten und die Environmental Parameters einzufügen. 42

43 Erfahrungen und Ratschläge

44 Erfahrungen und Ratschläge Die Qualität der Patches ist allgemein gestiegen, Nebenwirkungen sind relativ selten geworden. Vorsicht und intensives Testen ist bei kumulativen Sicherheitspatches und bei Patches, welche eine Funktionalität verändern, angesagt. Service Packs und Funktionalitätserweiterungen sollten getrennt vom Patchmanagement im normalen Change Prozess abgehandelt werden. Patching muss als normaler Betriebsprozess verstanden werden und nicht als etwas Verzichtbares. 44

45 Erfahrungen und Ratschläge Es ist von grosser Wichtigkeit, dass auch bei den Lieferanten und Kunden die nötige Awareness geschaffen wird. Das Patching sollte in SLAs geregelt werden. Am besten werden dazu regelmässig wiederkehrende Zeitfenster vereinbart. Lieferanten von Drittsoftware müssen bereit sein, vollständigen Support für die Applikation zu gewähren, auch wenn Security Patches für das OS eingespielt worden sind. Das regelmässige Patching innerhalb eines definierten Prozesses kann auch ein Verkaufsargument gegenüber dem Kunden sein. 45

46 Fragen und Diskussion