Eine der Aussagen bezog sich dabei auf die Zeit die Angreifer brauchen um nach bekannt werden einer (Zero Day) Schwachstelle einen entsprechenden Exploit zu schreiben.
Während es 2018 noch durchschnittlich 63 Tage gedauert hat bis Exploits für bekannt gewordene/gepatchte Sicherheitslücken vorhanden waren, dauerte es in 2023 durchschnittlich nur 5 Tage.
Leider sind viele Unternehmen immernoch so träge das mit Monatlichen Patchdays gearbeitet wird, obwohl es längst angemässen wäre Patch-cyclen in Stunden statt Tagen zu messen…
Einen wöchentlichen oder gar täglichen Security Patchday halte ich für übertrieben, solange kritische Security Patches auch ausser der Reihe ausgerollt werden, und dann auch zeitnah installiert werden. Es gab ja schon einige Fälle in der Vergangenheit, wo das Problem nicht eine Zero Day Sicherheitslücke war, sondern dass bereits vorhandene Security Patches nicht eingespielt waren. Zudem kann es neben den Security Patches auch andere Möglichkeiten der Absicherung verwundbarer Systeme geben.
Und: Die Security Patches müssen auch innerhalb von Firmen und Organisationen geprüft und erst dann ausgerollt werden. Man möchte nicht als Verantwortlicher einer Firmen IT sehen, dass nach der Installation eines Security Patches die Arbeitsplätze oder IT Infrastruktur lahmgelegt ist.
Fast alle großen ausgrnutzten exploits entstehen aus der Ignoranz der Hersteller. Man hält gewisse Lücken nicht für wichtig. Das bekannteste Beispiel ist wohl Pegasus
Da wurde der Angriff via einer manipulierten Bilddatei über imessage durchgeführt. Das alles nur weil Apple versäumt hatte (es nicht für wichtig befunden hatte) den JBIG2 Codec anzupassen.
Heute hält Apple es nicht für notwendig Lücken im USB C Port zu schließen.
Insgesamt ist Android da tatsächlich besser aufgestellt. Hier muss nämlich immer der Anwender den letzten Schritt in die Wege leiten
das halte ich weder für praktikabel noch wegen der Verzögerung für sinnvoll. Ich bevorzuge rausrollen zusammen mit der Möglichkeit über Backups auf den älteren Stand zurückzukommen. Ich kenne Organisationen die mit dem Argument „ungetestet“ Patches zwei Jahre verzögen - in meinen Augen unverantwortlich.
Ja, zwei Jahre ist definitiv unverantwortlich. Aber ein paar Tage Tests würde ich einem flächendeckenden Ausfall vorziehen (Crowdstrike lässt grüßen). Am Ende müssen das aber die Verantwortlichen entscheiden (Risikoabwägung).
Grundsätzlich ist das richtig. Um jedoch eine Brücke zu einem anderen Thread zu schlagen, den wir kürzlich diskutiert haben: In zertifizierten Anlagen dürfen beispielsweise keine Firmware-Updates einer Firewall eingespielt werden, die nicht ebenfalls den Zertifizierungsprozess durchlaufen haben. Das kenne ich allerdings nur aus der Fachliteratur, da wir selbst kein Betreiber solcher Anlagen sind. Ob bei Notfallpatches eine andere Vorgehensweise zulässig ist oder ob es nur Major-Releases betrifft, entzieht sich meiner Kenntnis. Aber diesen Gedanken hatte ich auch, als ich das gelesen habe.
Unsere Vorgehensweise bei Firewall-Updates sieht beispielsweise vor, dass wir das Update zunächst nur auf der sekundären Firewall einspielen. Wenn diese ohne Fehler hochkommt, wird sie zur primären Firewall erhoben. Im Fehlerfall können wir wieder auf die andere Firewall schalten. Wenn alles stabil läuft, spielen wir das Update auf der anderen Firewall ein. Aber nicht jeder hat ein Cluster und es ist auch nicht überall realisierbar. Bei Datenbankservern sind wir allerdings auch vorsichtig. Hier ist das Einspielen eines Snapshots nicht unbedingt das, was man wirklich möchte. Da sind Probleme quasi vorprogrammiert. Desaster Recovery eben. Bei normalen Systemen ohne hohe externe Abhängigkeiten hingegen ist ein klassisches Operational Recovery im Prinzip kein Problem.
Das ist schon eine Ausnahme vom Normalfall: die meisten Leute haben gar keine (ernsthafte) Redundanz (schon gar nicht auf Netzwerkebene) und idR verstehen sie auch nicht, welche Systeme kritisch sind oder welche Abhängigkeiten sie haben. Automatische Tests? Fehlanzeige.
Das Problem dabei ist das viele Patches sicherheitsrelevant sind ohne als solches gekennzeichnet zu sein. Auch Fehler die nicht auf den ersten Blick ausnutzbar sind stellen sich regelmäßig als Schwachstellen heraus. Und die Frage ist auch ob der Hersteller oder Betreiber Zeit dafür investieren sollte Fehler nach ihrer Sicherheitsrelevanz hin zu untersuchen wenn man auch einfach alle patches gleich behandeln kann.
Unabhängig ob patches oder andere Änderungen sollte die infrastruktur idealerweise sowieso so aufgebaut sein das automatisch getestet und notrfalls zurückgerollt werden kann.
Da die wenigsten Organisationen eine separate Testumgebung finanzieren wollen, wäre eine Option die ich als nächstes mal ausprobieren plane, das server cluster direkt in production so zu bauen das man außerhalb der stoßzeiten wenn nicht alle systeme gebraucht werden, einen Teil abspaltet, patched, tested und im Zweifel zurückrollt. Das kann dann automatisch passieren, so das vollständige Updates störungsfrei und theoretisch im Minutentakt durchgeführt werden können. Wenn der Softwareherstellen einen Notifications push service betriebt, könnte man auch Updates innerhalb von Sekunden nach Veröffentlichung ausrollen
Wenn KI tatsächlich noch besser wird, könnte das bald auch notwendig werden da diese ja auch theoretisch die Patches in 2 Sekunden reverse engineren und exploits ausrollen könnten bevor menschliche user auch nur die Release notes gelesen haben. Bin zwar selbst eher am zweifeln ob KI tatsichlich so gut wird aber wenn manche vorhersagen wahr werden, könnten Patch cyclen in 10 Jahren in millisekunden gerechnet werden…
In Debian-basierten Betriebssystemen gibt es Security-Repositories. Diese enthalten ausschließlich sicherheitsrelevante Aktualisierungen und werden unabhängig vom normalen Update-Zyklus gepflegt. Mithilfe des Unattended-Upgrades-Services können diese Aktualisierungen automatisch eingespielt werden. Das System führt auch selbstständig einen Neustart durch, falls eines der Updates das “reboot-required”-Flag setzt. Das Intervall der Suche kann beliebig eingestellt werden, allerdings sollte man dabei nicht zu hektisch vorgehen, da dadurch auch Last erzeugt wird. Sowohl auf dem eigenen System als auch auf dem Repositoryserver.
Meiner Erfahrung nach ist es nahezu unmöglich, eine Testumgebung für alle relevanten Systeme und vor allem deren Abhängigkeiten aufzubauen. Wer sich die Mühe macht, wird außerdem sehr schnell feststellen, dass sich die Systeme recht bald deutlich voneinander unterscheiden. Ich habe es jedenfalls aufgegeben. Wir haben zwar Testsysteme zur Update-Evaluierung, aber nur, um die gröbsten Schnitzer aussortieren zu können.
Bei Windows willst du das nicht wirklich. Fast alle Updates erfordern einen anschließenden Neustart. Zwar führt Microsoft derzeit schrittweise das Hotpatching ein, aber wie gut das funktioniert, muss sich erst zeigen. Tiefgreifende Updates werden auch weiterhin einen Neustart benötigen. Bei Linux ist man da schon weiter, da habe ich kaum Neustarts. Das kann aber auch daran liegen, dass man nicht inflationär mit dem Ausrollen solch großer Updates umgeht. Selbst wenn kein Neustart des gesamten Systems erforderlich ist, muss in der Regel wenigstens ein Dienst neu gestartet werden. Das möchte man auch nicht unbedingt im Hochbetrieb durchführen.
Das heißt dann aber auch, dass man „nur noch einen Softwarehersteller hacken muss“, dessen Updates so eingespielt werden und man hat innerhalb von Sekunden die halbe Welt gehackt …
Ich bin mir nicht mehr sicher, wie das Desaster damals hieß, aber vor ca. 2 Jahren haben sich viele großen Firmen auf diesem Wege einen bösen Krypto-Trojaner eingefangen. Das war irgend eine Steuersoftware und zu den Opfern hörte sogar Mearsk …
Wobei das ja nicht immer Schadsoftware sein muss. Es reicht schon das die IT-Firma irgendwas an der Konfiguration ändert und dann hängt beim Kunden das ganze System. Ein ehemaliger Kollege hat mir das mal erzählt, dass er sowas in seiner alten Firma mit SAP erlebt hat, da fehlte der Wechselkurs von Euro zu irgend einer anderen Währung und dann ging 3 Tage lang nichts mehr, bis die IT das Problem identifizieren konnte.
Das ist mir nicht bekannt. Kannst du bitte mal ein Beispiel nennen.
Firmen mit 50.000 MAs, auf der ganzen Welt - sprich in allen Zeitzonen - verteilt und ihr wollt „auf Teufel komm raus Security Patches einspielen und wenn es schief geht mal eben ein Backup einspielen“, um was zu gewinnen? 1 - 2 Tage vor einer möglichen Cyberattacke? Wenn das Einspielen des Security Patches die einzige Karte ist, die man hat und in Panik zieht, dann ist man nicht gut aufgestellt.
Mein AG macht das nicht. Security Patches in der IT werden zeitnah eingespielt, aber vorher getestet. Und:
Sekunden? Millisekunden? Ernsthaft? Damit die KPIs und Dashboards schön aussehen? Den IT Verantwortlichen möchte ich sehen, der da mitmacht.
Das Problem gab es ja zum Beispiel 2020 bei Solarwinds.
Maersk hatte 2017 den größten Cybervorfall (NotPetya), der die Firma 300.000.000 USD gekostet hat. Es handelte sich um einen Ransomware, mit der die Ukraine angegriffen wurde und Maersk und andere wie die Deutsche Bahn Kollateralschäden waren.
Und um nochmal auf die Zeit bis zum Einspielen eines Security Patches zu kommen, in der OT, insbesondere im Bereich der Industrieautomatisierung in kritischen Infrastrukturen, installiert niemand einen Security Patch für ein Betriebssystem sobald dieser vom Hersteller des Betriebssystems veröffentlicht wurde, sondern dieser wird erst vom Lieferanten geprüft. D.h. der Hersteller der Industrieautomatisierung prüft zunächst, ob der Security Patch überhaupt für sein System relevant ist und dann ob nach einer Installation das System weiterhin korrekt funktioniert. Und wenn beides gegeben ist, dann erhalten die Benutzer der Industrieautomatisierung den Security Patch und entscheiden, wann sie diesen installieren. Und letzteres kann durchaus mehrere Monate nach der Veröffentlichung durch seinen Lieferanten passieren.
und wie vollständig sind die Tests? Und warum soll Dein AG die Qualitätssicherung des Anbieters übernehmen? Vielleicht bei kritischen Anwendungen, aber nicht für jede Software.
Ja, Crowdstrike lässt grüßen, aber wer hat das vorher getestet?
Ich könnte jetzt mit der Gegenfrage „Was verstehst du unter Vollständigkeit?“ antworten. Nein, mein AG ist keine Garagenfirma, sondern hat eine adäquate IT, was ich sowohl an meiner Erfahrung mit eben dieser als auch an den Prozessualen, Imformationen, Audits und Zertifizierungen ausmache.
Sichert mir z.B. Microsoft zu, dass ein Patch auf allen meinen Geräten problemlos läuft? Selbst wenn der Hersteller Kriterien für Kompatibilität nennt, so ist es den Aufwand und die Zeit wert, dies für die eigenen Geräte zu testen, bevor viele plötzlich Probleme haben.
Eine ideale und aus heutiger Sicht geradezu utopische Infrastruktur die in Sekunden patches verteilt hätte auch sicher kein Windows (oder übliches Linux/Mac). Zwar war mein Kommentar primär auf server Umgebungen ausgerichtet, aber mit modernen Clients wie ChromeOS/Android ist das durchaus denkbar.
Das war Solarwinds aber hatte auch nichts mit Automatisierung der Updates zu tun. Was soll der Unterschied sein wenn der Hersteller kompromittiert ist und du schadcode bekommst der erst Wochen später oder durch eienn Trigger ausgelöst wird. Wie willst du das finden? Hast du tausende Entwickler die nichts anderes tun außer die Patches zu disassemblen? Die Automatisierung der Updates macht da keinen unterschied, der Angriff ist in jedem Fall möglich.
Separate Testsysteme können grobe Fehler finden bevor Patches in die Produktionsumgebung gehen, aber das ist auch nicht zuverlässig. Überhaupt sollten alle derartig zu finden Probleme doch längst von Hersteller durch viel umfangreichere Tests abgefangen werden. Wenn Hersteller da wiederholt versagen muss man eben alternativen anschaffen
Was Android angeht, hat Google offenbar eine extrem prekäre Änderung in der Veröffentlichungspolitik seiner Sicherheitspatches gemacht. Diese sollen großteils nur noch alle 3-4 Monate zu Android released werden, während OEMs diese bereits vorab mit teils ebenso langem Vorlauf erhalten - mit der großen Gefahr einhergehend, dass potentielle Angreifer ebenso an diese Vorabveröffentlichungen gelangen und so viel Zeit zur Entwicklung entsprechender Exploits und Ausnutzung dieser Schwachstellen haben.
Angeblich soll dies ein Zugeständnis an OEMs sein, um diese besser aussehen zu lassen, was das Einpflegen von Updates anbelangt, aber de facto aus Sicherheitsaspekten eine schiere Katastrophe darstellt.
Sieht in der Tat nach einem Rückwärtsschritt aus, auch wenn das Graphene Team scheinbar eine Lösung zur Umgehung gefunden hat.
Wird Zeit das die EU endlich ihre Vorgaben verschärft und nicht nur die Dauer der Updates vorschreibt sondern auch die Geschwindigeit. Wer digitale Produkte verkauft, muss Patches innerhalb von 48 Stunden bereit stellen sonst Verkaufsverbot! Das schafft scheinbar auch fast jedes Open Source projekt
Alles weitereist bisher nur Wunschdenken. Die Hoffnung ist das die EU bemerkt das 5 Jahre Updates ziemlich Nutzlos sind wenn man dem Hersteller beliebig Zeit lässt die Updates auch zu veröffentlichen. 48 Stunden nach bekannt werden einer Schwachstelle wäre da schon eine bessere Vorgabe
Die Richtlinie bezieht sich auf Smartphones und Tablets, da bleiben dann Smarte Geräte und IoT und andere Gerätekategorien außen vor, was sehr bedenklich ist. Botnetzbetreiber werden sich freuen.
Ich meine gelesen zu haben, dass die EU auch eine ähnliche Richtlinie herausgegeben hat, die auch andere Gerätekategorien mit einbezieht, oder ich habe das nur geträumt.
