Ich weiß nicht, ob wirklich begriffen wurde, in welch desolater Situation sich die IT-Sicherheit durch die KI inzwischen befindet.

Die gravierenden Sicherheitslücken der letzten Wochen ( "dirtyfrag" , "copyfail" , "fragnesia" ) haben zudem einigen Staub aufgewirbelt, der wichtige Denkprozesse anstoßen sollte. Und dennoch sind sie vermutlich erst der Anfang dessen, was uns da blüht. Wenn ich lese , dass funktionierende KI-generierte Exploits inzwischen in unter einer Stunde gebaut werden können und wenn ich dann weiter lese, dass Exploits teilweise sogar schon vor dem Release der aktualisierten Software vorhanden sind bzw. aus den durch das Update entstandenen Programmänderungen (diff) KI-generierte Exploits gezielt auf noch nicht aktualisierte Systeme losgelassen werden, dann empfinde ich das als höchst alarmierend. Faktisch nehmen die globalen Angriffe zu , was u.a. auch das BSI thematisiert . Und die zusätzliche Arbeit der Sicherheitskorrekturen muss ja auch bewältigt werden .

Durch die "Privatisierung" der LLMs (also das lokale Betreiben einer KI auf dem eigenen Rechner) wird die Situation garantiert nicht besser, weil so jedes Scriptkiddie ( WP ) noch leichter irgendwelchen Blödsinnscode zusammenstricken kann.

Was kann man da tun (als AnwenderIn, als halbwissender Admin)?

Zunächst einmal frage ich mich, ob die etablierten Konzepte Stable/Testing/Unstable der Linux-Distributionen heute überhaupt noch zeitgemäß sind.

Denn die Zeit, um neue Programmversionen auf Fehler und Stabilität zu testen, die haben wir heute faktisch nicht mehr und "Stable" wird immer mehr ein relativer Begriff bzw. sagt nicht viel über die Sicherheit der Software aus. Das herkömmliche Konzept der festgelegten Patchfenster funktioniert einfach nicht mehr, so dass wir zwangsläufig zu kontinuierlichen Aktualisierungen gezwungen sein werden. Wie das mit dem Wunsch gleichzeitiger Stabilität der Software zu vereinbaren ist, muss noch ausdiskutiert werden so wie die Frage, ob neue Feature-Releases zeitnah veröffentlicht oder doch lieber erst genauer durchgetestet werden sollten.

Unter Rückgriff auf die in der Corona-Zeit geführten Diskussionen, ab wie viel Prozent der durchgeimpften Bevölkerung wir gesamtgesellschaftlich hinreichend geschützt sind, kann man ähnliche Überlegungen zum "Durchpatchungsgrad" der IT-Systeme anstellen - und muss die unschöne Diskussion darüber führen, wie das durchzusetzen und zu überwachen ist (Impfpflicht/Updatepflicht). Denn so wie es ImpfgegnerInnen gab, so gibt es auch Leute, die chronisch ihre Systeme nicht patchen und somit ebenfalls möglicherweise andere IT-Systeme gefährden. Vor diesem Hintergrund lohnt es sich, die Folgen der noch nicht endgültig "aufgeräumten" AUR-Kompromittierung zu durchdenken.

Als einen wichtigen Teilschritt würde ich es explizit begrüßen, wenn (auch wenn das organisatorisch und technisch schwierig ist) Sicherheitsupdates und Featureupdates voneinander getrennt würden (z.B. in unterschiedlichen Repo-Zweigen). Die unterschiedliche Relevanz dieser Beiden sollte klar sein: Sicherheitsupdates sollten so schnell wie möglich eingespielt werden, während Featureupdates ein nice to have sind. Allerdings bin ich (anders als das, was einem ewig vorgetrötet wird) kein Freund davon, diese automatisch einzuspielen, da ich zunächst sehen will, was aktualisiert wird: Mindestens schon 2x ist mir durch unbedarftes Aktualisieren die grafische Oberfläche fliegen gegangen, was höchst ärgerlich ist und schlimmstenfalls zu Datenverlust führen kann. Bestenfalls könnte ich mich mit dem Konzept der Unattended Upgrades anfreunden (nur auf Stable, aber niemals auf Testing/Unstable-Systemen!) und mahne selbst hier zur Vorsicht .

Mir ist aber natürlich klar, dass Probleme u.a. auch dadurch entstehen, dass AnwenderInnen längerfristig die Updates einfach nicht einspielen wollen ("das nervt gerade", "es funktioniert doch alles", usw.)

Hinzu kommt, dass "einfach nur Updates einspielen" nicht ausreichend ist. Bei Stable-Systemen recht selten, aber bei Testing/Unstable sehr häufig kommt es zu sich ändernden Paketabhängigkeiten, so dass nach der Aktualisierung die entsprechenden Aufräumarbeiten anstehen, die sich aber recht gut halbautomatisch erledigen lassen. Auch dies ist wichtig, denn veraltete Pakete auf dem System fressen nicht nur Platz, sondern stellen auch eine potenzielle Gefahr da.

Seit dem KI-Hype überprüfe ich mehrmals täglich die am Netz hängenden Systeme auf vorhandene Updates, was faktisch einer täglichen "Verschwendung" von Arbeitszeit entspricht.

Generell empfehle ich die Systeme schlank zu halten. Denn Software, die gar nicht erst installiert ist, stellt auch keine potenzielle Gefahr dar.

Wie gesagt: Die etablierten Releasezyklen und -konzepte sind zu hinterfragen, da quasi "alles sofort" zur Verfügung stehen muss. Von Unstable hin zu Testing finden in der Debian-Welt automatisierte Softwaretests statt, die wenigstens die schlimmsten bekannten(!) Fehler finden können. Bis die dann stabilisierten und sicherheitsgepatchten Pakete aber in Stable ankommen, kann es in Zeiten von KI schon zu spät sein (abgesehen davon, dass Sicherheitspatches gar nicht erst explizit in Testing eingepflegt werden). Daher müssen Sicherheitsupdates von Featureupdates getrennt werden, da Zweitere eine wohl längere Phase der Stabilisierung benötigen - was aber nicht bedeutet, dass Sicherheitsupdates keine Probleme bereiten können.

Schon seit Jahren rede ich mir den Mund fusselig/schreibe ich mir die Finger wund mit dem Hinweis, das eigene System jeweils auf einer separaten Partition als IMAGE zu sichern, um so im Falle eines (aus welchen Gründen auch immer) defekten Systems schnellstmöglich wieder arbeitsfähig zu sein (denn ich habe noch andere "Hobbies" als Systeme neu zu installieren). Seit ein paar Jahren arbeite ich mit dem recht eingängigen fsarchiver ( UU ), der exakt das tut, was er soll: Partitionen einpacken in Dateien und umgekehrt.

Die mir höchst unsympathischen "unveränderlichen/immutable" Distributionen mit ihren a/b-Update- und Boot-Systemen könnten noch an Relevanz gewinnen, da dieses völlig neue Konzept Distributionen zu bauen und zu betreiben, durchaus Vorteile hat.

Sympathischer finde ich da semi- rollende /"kuratiert rollende" ( WP ) Distributionen wie Manjaro (reizt mich persönlich nicht, aber sie arbeitet nach diesem interessanten Update-Prinzip), die in festen Zyklen aufgelaufene und getestete Aktualisierungen erhält, die dann in sich konsistent sind und die somit nicht das System zerlegen (ein bei Rollenden Distributionen bekanntes Problem).

Allerdings lösen sie natürlich nicht das Problem der nötigen "Sofortness" bzgl. der Sicherheitsupdates. Aber sie bieten den hinreichend stabilen Kompromiss zwischen veralteten release-basierten und den aktuellen aber "instabilen" Rollenden Distributionen.

Wer über den Distributions-Horizont blickt, wird vielleicht auch mit openSUSE Tumbleweed oder Slowroll glücklich.

In noch stärkerem Maße werden Schutzmechanismen der Systeme selber wichtiger werden:

• Containerisierung/Abkapselung der Anwendungen, wie dies beispielsweise Core OS ( WP ) bietet, damit eine einzelne kaputte Anwendung nicht gleich das ganze System in den Abgrund reißt. Mit Bordmitteln geht das bei den etablierten Systemen aber auch, wenn man sich damit beschäftigt.
• Erweiterte Schutzmechanismen wie SELinux ( WP ) oder AppArmor ( WP ), um die Rechte der Anwendungen auf das Nötige einzudämmen und Privilegieneskalation durch ausgenutzte Sicherheitslücken ( WP ) zu unterbinden.
• Außerdem Intrusion Detection Systeme ( WP , BSI )
• Überwachungsdienste wie File Alteration Monitor ( WP ) zeigen verdächtige Veränderungen im Dateisystem an, können aber natürlich keine qualitative Aussage über die Art und Risiken der Veränderungen machen.
• Kernel Live-Patching ( WP ) - ein höchst umstrittenes Konzept, vor allem in Kombination mit dem strittigen "Kernel-Kill-Switch" kann helfen, die lästige Zeit des Systemneustarts zu verhindern, was speziell im Serverbereich wichtig ist.
• Die Installation einer wirksamen Firewall. Virenscanner dagegen sind konzeptioneller Mist, der schlimmstenfalls mehr schadet als nützt.

Außerdem:

Die zunehmende Verwendung der speicher- und typensicheren Programmiersprache Rust ist sehr zu begrüßen, da so immer wiederkehrende Fehler der C-Dialekte verhindert werden, so dass die Quellcodequalität nachweislich steigt.

Auch Reproduzierbare Pakete erhöhen die Möglichkeiten der Kontrolle.

Noch lautstärker mahne ich an:

• Die Standarisierung von Formaten und Schnittstellen kann schützen.
• Open Source kann wg. Überprüfbarkeit des Quellcodes schützen. Ich persönlich plädiere dafür, proprietäre Software vollständig zu verbieten, da sie faktisch nicht überprüfbar ist und den/die ComputeranwenderIn in die Abhängigkeit und den Goodwill des Softwareanbieters verstrickt.

Und Monopolisierungen sind eine weitere große Gefahr. Daher:

• Auch wenn man es immer wieder ins Hirn gehämmert bekommt, dass SystemD "alternativlos" sei, so stimmt das einfach nicht und es sind die Möglichkeiten und Grenzen anderer Init-Systeme auszuloten.
• Die neuartigen Paketformate bieten zwar den Vorteil der Containerisierung. Aber: Wenn hier ein Problem auftaucht, dann sind die Pakete auf allen Distributionen gleichermaßen angreifbar. Es gilt zu bedenken, dass die Vielseitigkeit der Systeme und Anwendungen auch ein wirksames Schutzkonzept ist.
• Und der mögliche Einsatz von nicht ganz so fetten Anwendungen (und Distributionen) ist zu bedenken, da einfachere Anwendungen vielleicht auch ausreichend sind für die jeweilige Aufgabe.
• Je nach Anwendungsszenario ist der Live-Betrieb ( WP ) im readonly-Modus ein funktionales Arbeitskonzept. Für die tagtägliche Arbeit auf dem Desktop ist dies aber ein höchst unbefriedigender Workflow.

Insgesamt zeigt sich also, dass wir in Zeiten uns zuballernder KI-Exploits die gesamte Sicherheitskette überdenken müssen.

Als Reaktion auf die KI-Bug-Schwemme baut die Linux Foundation zusammen mit den wichtigsten Tech-Giganten gerade die Koordinierungsstelle Akrites auf, um die EntwicklerInnen beim Umgang mit Sicherheitslücken zu entlasten, dabei mitzuhelfen die Software zu härten und so die Open-Source-Sicherheit zu unterstützen ( fosstopia , heise , Linux Magazin ). Wir haben ja am Schlingerkurs der Projektbetreuer des Downloaders Curl ( heise ) gesehen, das hier eine Notwendigkeit besteht, da die ProgrammiererInnen durch diesen ganzen KI-Bug-Schrott nicht mehr arbeiten konnten und sogar das Bug-Bounty-Programm einstellen mussten - womit niemandem geholfen ist ( LM , SI ). Mit Unterstützung durch diese Koordinierungsstelle können sich die ProgrammiererInnen dann hoffentlich endlich wieder auf ihre Arbeit konzentrieren.