In diesem ausführlichen Leitfaden erfahren Sie, warum Sicherheitsteams von Schwachstellen überwältigt werden, welche Gefahr sich hinter der doppelten Meldung von Schwachstellen verbirgt und wie Sie solche Schwachstellen mit Live-Patching-Tools wie KernelCare mindern können.
Wir wissen, dass die Cybersicherheitsbedrohung wächst, mit entsprechendem Wachstum bei den Bemühungen, die Bedrohung und die damit verbundenen Kosten zu mindern. Es gibt jedoch Anzeichen dafür, dass die Schadensbegrenzung nicht schnell genug voranschreitet.
Laut einer gemeinsamen Analyse durchgeführt von McAfee und das Zentrum für strategische und internationale Studien , 2020 werden die weltweiten Kosten der Cyberkriminalität auf über 1 Billion US-Dollar steigen Marke zum ersten Mal - ein massiver Anstieg von 50 % gegenüber dem Gesamtwert von 2018. Das ist eine Änderungsrate, die jede vergleichbare Kennzahl wie das BIP-Wachstum oder das Wachstum der IT-Ausgaben deutlich übertrifft.
Bewusstsein ist nicht das Problem – schließlich geben Unternehmen enorme Summen für die Abwehr von Cyber-Bedrohungen aus.
Stattdessen argumentieren wir in diesem Artikel, dass Cybersicherheitsakteure von den Herausforderungen, denen sie gegenüberstehen, im Wesentlichen überwältigt sind. Als eindeutigen Beweis weisen wir auf ein kürzlich aufgetretenes doppeltes Melden bekannter Schwachstellen hin.
Lesen Sie weiter, um zu erfahren, warum Sicherheitsteams von Schwachstellen überwältigt werden, wie sich dies auf das Patchen auswirkt und was Teams tun können, um angesichts eines unerbittlichen Ansturms von Schwachstellen und Exploits konsistent zu patchen.
Noch eine Schwachstelle?
In der zweiten Hälfte des letzten Jahres wurde eine Sicherheitslücke im Linux-Kernel entdeckt und gemeldet. Ihm wurde ein C zugewiesen ommon V Schwachstellen und E xposures (CVE)-Nummer, CVE-2020-29369 , und die Schwachstelle wurde wie erwartet gepatcht. Soweit nichts Ungewöhnliches.
Auch an der Verwundbarkeit selbst war nichts Außergewöhnliches. In jedem Betriebssystem muss der Kernel den Speicher sorgfältig verwalten – Speicherplatz zuweisen (zuordnen), wenn eine Anwendung ihn benötigt, und Zuweisungen korrekt entfernen und freien Speicher neu zuweisen, wenn eine Anwendung ihn nicht mehr benötigt.
Dieser Prozess der Speicherplatzverwaltung kann jedoch störanfällig sein. Wenn sie ohne die nötige Sorgfalt codiert werden, können Kernel-Speicherverarbeitungsprozesse Cyberkriminellen eine Chance geben. Im Fall von CVE-2020-29369 trat das Problem in der mmap-Funktion auf, die für die Speicherzuordnung unter Linux verwendet wird.
Die Art der Schwachstelle bedeutete, dass zwei unterschiedliche Anwendungen Zugriff auf denselben Speicherplatz anfordern konnten – was zu einem Kernel-Absturz führte.
Wenn ein Angreifer seine Karten richtig ausspielte – mit anderen Worten, einen Exploit konstruierte – wäre der Angreifer in der Lage, Daten zu stehlen, die sonst durch den Kernel geschützt wären. Dabei kann es sich um völlig harmlose Daten handeln – oder um etwas Wertvolleres, wie z. B. wertvolle persönliche Daten oder Passwörter.
Eine Geschichte von zwei Schwachstellenberichten
Wir können also sehen, dass eine typische Schwachstelle gemeldet und wie üblich akzeptiert wurde. Aber als nächstes geschah etwas Beunruhigendes.
Nur wenige Monate später wurde genau dieselbe Schwachstelle gemeldet. Wieder wurde eine CVE-Nummer vergeben, diesmal CVE-2020-20200 . Es stellte sich jedoch bald heraus, dass die neue Schwachstellenwarnung ein Duplikat einer anderen Schwachstelle war – CVE-2020-29369.
Die Forscher, die die Schwachstelle aus irgendeinem Grund ein zweites Mal „gefunden“ haben, konnten die erste Instanz der Schwachstelle nicht finden, bevor sie eine weitere CVE-Reservierung für das, was sie entdeckt hatten, anforderten. Eine der Hauptabsichten der CVE-Datenbanken besteht darin, doppelte Meldungen zu vermeiden, aber in diesem speziellen Fall wurde dennoch eine weitere CVE angefordert.
Dieser Fall der sogenannten "doppelten Meldung" ist nicht der erste oder einzige Fall, in dem eine Schwachstelle zweimal gemeldet wird. Schlimmer noch, wenn Untersuchungen zu einer Schwachstelle zu dem Punkt kommen, an dem ein CVE zugewiesen wurde, wurde die Schwachstelle bereits von zahlreichen hochqualifizierten Sicherheitsexperten überprüft.
Sogar Sicherheitsforscher können es verwechseln
In diesem Beispiel der doppelten Meldung ist klar, dass Sicherheitsforscher sich entweder der vorhandenen Schwachstelle bewusst sein oder die vorhandene CVE hätten finden müssen, wenn sie die „neue“ Schwachstelle ausreichend recherchiert haben, bevor sie eine neue CVE-Nummer angefordert haben.
Es ist ein beunruhigender Gedanke. Diese Memory-Mapping-Schwachstelle liegt im Kern des Linux-Kernels, aber Sicherheitsforscher waren sich dessen offenbar nicht bewusst, daher die doppelte Auflistung. Schlimmer noch, es ist nicht so, dass jede Auflistung ein Jahrzehnt oder sogar Jahre auseinander lag:Die einzelnen Auflistungen derselben Schwachstelle wurden im Abstand von nur wenigen Monaten erstellt, eine im August 2020 und eine im November 2020.
Sind Sicherheitsforscher fahrlässig? Nein. Sicherheitsforscher sind einfach völlig überfordert von der schieren Menge an Cybersecurity-Herausforderungen. Aus diesem Grund haben Linux-Kernel-Sicherheitsexperten in diesem Beispiel einen vorhandenen Bericht über eine potenziell kritische Schwachstelle übersehen.
Die versteckte Gefahr hinter der doppelten Meldung von Schwachstellen
Klare Beweise dafür, dass die Cybersicherheitsbedrohung zunimmt, kombiniert mit Beispielen, bei denen selbst Sicherheitsexperten etwas falsch machen, deuten darauf hin, dass die doppelte Meldung größere Auswirkungen hat, als es auf den ersten Blick scheint.
Es bedeutet nicht, dass Linux-Sicherheitsexperten anfällig für Fehler und Versehen sind. Es deutet einfach darauf hin, dass die Aufgabe, Sicherheitslücken zu verwalten, so unglaublich schwierig geworden ist, dass selbst die Experten Schwierigkeiten haben, Schritt zu halten.
Stellen Sie sich für einen Moment ein typisches internes Technologieteam vor, das einen umfassenden Aufgabenbereich hat – ja, einschließlich Sicherheit, aber auch Wartung, Betrieb und eine endlose Anzahl anderer Verantwortlichkeiten.
Selbst wenn Unternehmensteams über dedizierte Sicherheitsexperten verfügen, besteht die Möglichkeit, dass Fachwissen über eine Reihe von Bedrohungen und Technologietools hinweg angewendet werden muss. Selbst für ein großes Unternehmen wäre es äußerst selten, einen Linux-Kernel-Sicherheitsexperten einzustellen. Und selbst wenn, wie wir gesehen haben, können diese Sicherheitsexperten Fehler machen.
IT-Teams stehen harte Zeiten bevor
Teams vor Ort werden Sicherheitslücken immer bis zu einem gewissen Grad verwalten. Indem Sie beispielsweise auf Nachrichten über größere Exploits reagieren und entsprechende Patches anwenden. Auch Warnungen von Anbietern können zu Maßnahmen führen, und die meisten guten IT-Abteilungen verfügen über eine Art von Patching-Regelung, die sicherstellt, dass Patches in festgelegten Intervallen angewendet werden.
Aber wie können IT-Teams realistischerweise mit einer wachsenden Menge von CVEs Schritt halten, die Linux-Distributionen auf breiter Front betreffen und täglich eingehen. Bietet beispielsweise ein vierteljährliches Patch-Regime wirklich ausreichende Sicherheit? Und ja, Patching ist wichtig , aber sollte es die Aktivität auf Kosten von allem anderen dominieren - was angesichts der Menge an Patches leicht passieren kann?
Es ist leicht zu erkennen, dass es für IT-Teams schwierig sein wird, mit der ständig wachsenden Liste von Schwachstellen Schritt zu halten.
Machen Sie Ihr Patch-Regime richtig
Die Formalisierung Ihres Patching-Regimes ist der erste Schritt bei dem Versuch, mit dem Berg von CVEs fertig zu werden. Ad-hoc-Patches, die auf alarmierenden Nachrichtenberichten basieren, sind nicht der richtige Weg – es gibt einfach zu viele Schwachstellen, und relativ wenige werden allgemein bekannt – und hinterlassen unzählige versteckte Schwachstellen und damit verbundene Exploits, die eine Gefahr darstellen.
Nichtsdestotrotz ist einer der wichtigsten Schritte bei der Erstellung eines Patching-Regimes die Priorisierung von Patches. Kritische, weithin bekannte Schwachstellen müssen schnell gepatcht werden – ohne Verzögerung und wenn nötig auf Kosten der Verfügbarkeit. Patches für Sicherheitslücken mit mittlerem und niedrigem Risiko könnten so geplant werden, dass sie zu den Arbeitslasten von Technikteams passen oder Probleme mit der Verfügbarkeit vermeiden.
Ein weiterer wichtiger Schritt besteht darin, ein ausreichend vollständiges Inventar der Hardware und Software zu erstellen, die gepatcht werden muss. Einige Ziele für das Patchen sind sofort offensichtlich, andere können jedoch leicht übersehen werden.
Beim Aufbau Ihres Inventars können Sie auch einen gewissen Spielraum für die Standardisierung erkennen – mit anderen Worten, Software auf die gleiche Version aktualisieren oder Anbieter konsolidieren, um die Verwaltung von Patches zu vereinfachen.
Schließlich lohnt es sich, Ihr Patching-Regime in einer formellen Patching-Richtlinie zu kodifizieren. Es ist schwierig, konsistent Patches durchzuführen, und es genügt ein einziger Fehler, um der Katastrophe Tür und Tor zu öffnen. Ein kodifizierter Patching-Plan kann Ihrem Team dabei helfen, mit dem Patchen auf Kurs zu bleiben – Jahr für Jahr.
Der Kompromiss beim Patchen
Bei jedem Patching-Regime muss normalerweise ein Kompromiss zwischen Verfügbarkeit und Sicherheit eingegangen werden. Ja, Sie können auf höchst sichere Weise patchen – Patches so schnell anwenden, wie sie veröffentlicht werden. Das Patchen wirkt sich jedoch zwangsläufig auf die Verfügbarkeit aus, da das Patchen häufig Serverneustarts erfordert.
Tatsächlich können einige Unternehmen spezielle Geschäftsanforderungen haben, die verhindern, dass Dienste oder Server heruntergefahren werden, um Patches anzuwenden, selbst wenn ein kritischer CVE auftritt, wodurch Dienste anfällig für einen neuen Exploit werden können.
Selbst wenn Sie Server zu Wartungszwecken offline schalten können, werden die Dienste und damit die Endbenutzererfahrung beeinträchtigt. Stellen Sie sich zum Beispiel einen Online-Händler vor, der Tausende von Kunden online hat und plötzlich die Hälfte seiner Server zu Wartungszwecken vom Netz nimmt.
Hinzu kommt die Belastung der Technikteams, die unweigerlich Zeit für andere Aufgaben opfern, um Zeit für das Patchen aufzuwenden. Sicherheitsteams könnten von der Last des Patchens einfach völlig überfordert sein. Es gibt jedoch eine Alternative.
Erwägen Sie automatisierte Patching-Tools
Wir haben zwei Hauptprobleme hinter Standard-Patching-Regelungen identifiziert:die Zeit und den Aufwand, die für das Patchen erforderlich sind, und die mit dem Patchen verbundene Unterbrechung. Eine erwägenswerte Lösung ist das automatisierte Patchen – und noch mehr, wenn es sich um ein automatisches Patchen ohne Neustart handelt das Patches anwendet, ohne dass Serverneustarts erforderlich sind.
Automatisierte Patching-Tools überwachen kontinuierlich Patch-Releases und wenden diese Patches automatisch ohne Eingriff an. Es entfällt die Notwendigkeit, Personal für das Patchen von Serverflotten bereitzustellen – das Patchen erfolgt einfach nahtlos im Hintergrund. Mit automatisiertem Patchen werden Technikteams nie mit unzähligen Patchaufgaben überfordert, noch müssen Technikteams versuchen vorherzusagen, welche Patches am wichtigsten sind. Stattdessen werden alle Patches nahtlos, gleichmäßig und konsistent angewendet.
Einige automatisierte Patching-Tools wie KernelCare kann Patches on-the-fly anwenden – live patchen, während eine Maschine läuft und ohne dass ein Neustart erforderlich ist. Live-Patching begrenzt Unterbrechungen, da Maschinen nicht offline geschaltet werden, um einen Patch zu verarbeiten. Wenn das Risiko einer Unterbrechung minimal ist, wird sich die Patching-Konsistenz wahrscheinlich verbessern.
Mit anderen Worten, das richtige automatisierte Patching-Tool kann zwei der größten Probleme lösen, mit denen Unternehmen beim Patchen konfrontiert sind:erforderlicher Aufwand und Unterbrechungen.
Patching ist entscheidend, egal wie Sie es wählen
Was auch immer Ihr Unternehmen tut, um sich für das Patchen abzusichern, oder wie auch immer Sie Ihr Patching-Regime gestalten, die einzige Gewissheit ist, dass Patchen von entscheidender Bedeutung ist. Patches müssen angewendet werden, aber es muss eine Entscheidung darüber getroffen werden, wie oft und wie gepatcht wird.
Angesichts der Größe der Cybersicherheitsbedrohung gibt es starke Argumente für automatisiertes Patchen. Tech-Teams und Sicherheitsforscher sind gleichermaßen zunehmend überfordert und automatisiertes Patchen überbrückt das Ressourcen- und Verfügbarkeitsproblem.
Es ist immer eine Option, einfach mehr Personal für die Patching-Herausforderung einzusetzen, und für einige Workloads ist dies möglicherweise die einzige Option. Doch in den meisten Fällen kann automatisiertes Patchen ohne Neustart einen großen Gewinn gegen die enormen Herausforderungen der heutigen Cybersicherheit bringen.
Empfohlene Lektüre:
- Patch Raspberry Pi Linux Kernel mit KernelCare KOSTENLOS!
- Veraltete gemeinsam genutzte Bibliotheken im Arbeitsspeicher mit UChecker erkennen