Edition 16

Bei RubyDoc wurde nichts ausgenutzt. YARD lud ein Skript, auf das der Paketautor es hinwies, eine dokumentierte, korrekt funktionierende Funktion. Die Agenten haben das Build-System nicht gebrochen, sie haben es genutzt. Ihre Pipeline gewährt jedem Paket und jeder Konfigurationsdatei darin dasselbe Vertrauen. Wenn Sie die Build-Umgebung eher als Werkzeug denn als Produktionsumgebung behandeln, ändern Sie das diese Woche.

Und halten Sie das Muster fest. Drei Vorfälle, keiner zuerst von der Partei offengelegt, die davon wusste. Die RubyGems-Maintainer verbrachten vier Monate damit, nicht zu wissen, wer ihnen einen DDoS zugefügt hatte. Das Wiki wurde von einem einzigen Freiwilligen abgewehrt, der Seiten manuell löschte. Bleiben Sie bei den Fakten fair: Eine Untersuchung braucht Zeit. Aber wenn die Organisation, die die Logs besitzt, nicht diejenige ist, die Sie informiert, erfahren Sie es von einem Freiwilligen mit einem Löschen-Button.

Silicon Valley hat entdeckt, dass man ein System kontrollieren sollte, bevor man es verbessert. Willkommen in Europa. Wir nennen es AI Act, NIS2 und DORA, und wir haben drei Jahre damit verbracht, uns sagen zu lassen, das sei innovationshemmende Bürokratie. Der einzige Vorsprung, den sie uns gegenüber haben: Sie sagen es, nachdem etwas kaputtgegangen ist.

Nehmen Sie die Warnung trotzdem ernst, und beachten Sie gleichzeitig das Timing. Dann reduzieren Sie den Plan auf das, worauf Sie handeln können: unabhängige Evaluatoren mit echtem Zugang, die die Logs lesen und bestätigen, dass das System innerhalb seiner Grenzen geblieben ist. Das ist Third-Party Assurance, und genau dort landet der Enterprise-Ratschlag aus der anderen Richtung. Eine Identität pro Agent, Anmeldeinformationen, die mit der Aufgabe ablaufen, jemand außerhalb des Teams, der die Logs liest. Das ist Access Management und ISO 42001, angewendet auf eine neue Art von Nutzer.

Dies ist der Teil der Lieferkette, den Ihr SBOM nicht abdeckt. Wir haben den Sommer mit npm-Würmern und Software Bills of Materials verbracht, und all das inventarisiert, was Sie kompilieren und ausliefern. Dieses hier läuft im Browser Ihres Kunden, von einem fremden Server, mit vollem Zugriff auf Ihr Zahlungsformular. Und Sie haben den Mechanismus hier bereits zweimal gesehen: das Postfach des ehemaligen Mitarbeiters, das niemand gelöscht hat, die abgelaufene Visa-Karte, die noch immer Zahlungen autorisierte. Abgelaufen ist nicht widerrufen. Jemand hebt die Schlüssel auf, die Sie weggeworfen haben.

Montagnachmittag, und das hier ist einfach. Stellen Sie eine Content Security Policy im Report-only-Modus für eine Woche bereit. Sie erzwingt nichts und blockiert nichts. Sie zeigt Ihnen lediglich, was in den Browsern Ihrer Nutzer ausgeführt wird, und diese Liste ist immer länger, als jemand erwartet.

Lesen Sie diese Daten sorgfältig, denn die Schlagzeile, die alle wiederholen, ist die falsche. Server 2022, das den Mainstream-Support verlässt, ist kein End of Life. Es erhält weitere fünf Jahre lang kostenlose Sicherheitsupdates. Die wirklich relevanten Daten sind 2012 R2, dessen letzte ESU am selben Tag ausläuft, und 2016 im Januar, möglicherweise ohne kostenpflichtige Möglichkeit, mehr Zeit zu kaufen.

Was das Ganze gefährlich macht, ist das Thema dieser gesamten Ausgabe: Nichts bricht zusammen. Am 13. Januar 2027 booten die Server, die Anwendungen laufen, niemand bemerkt es. Die einzigen, die eine Entscheidung erzwingen, sind Ihr Auditor, Ihre Versicherung und Ihre Anbieter, die die Version aus ihren Support-Matrizen streichen, und alle drei kommen nach dem Stichtag. Behandeln Sie es als Asset-Lifecycle-Management, nicht als Patching. Wenn Sie noch von 2012 und 2016 migrieren, während 2022 hinter Ihnen den Status wechselt, haben Sie keinen Patching-Rückstand. Sie haben einen Friedhof von Betriebssystemen und keinen Bestattungsplan.

Endlich. Ich setze Decoys überall dort ein, wo ich arbeite, und überall, wo meine Teams arbeiten. Versteckt im Netzwerk, in Dateifreigaben, in Konten, die real aussehen und niemandem gehören. Fast niemand denkt darüber nach, und jetzt gibt es ein kostenloses Regierungsdokument, das Sie Schritt für Schritt durch die Umsetzung führt. Die Ausrede ist weggefallen.

Blicken Sie auf diese Ausgabe zurück, und Sie sehen, warum sie hier endet. Agenten, die mit legitimem Zugang eine Build-Umgebung durchstreifen. Ein Skript, das im Browser Ihres Kunden mit Ihren Rechten läuft. Anmeldeinformationen, die ihren Eigentümer überlebt haben. Nichts davon bricht etwas, und genau deshalb bleibt Ihr Tooling still. Ein Decoy kehrt das um: Niemand Legitimes hat irgendeinen Grund, einen Honeytoken anzufassen; wenn einer auslöst, erhalten Sie Signal mit nahezu keinem Rauschen. Bauen Sie es sauber auf. Ein schlechter Decoy ist eine Haftungsquelle. Und behandeln Sie diese Anleitung nicht so, wie die meisten Menschen ihre Audit-Berichte behandeln: einmal gelesen, abgelegt, vergessen. Der Decoy, den Sie bereitstellen, ist die Kontrolle. Das PDF ist nur Papier.