Thema
Sicherheitsautomatisierung
Innerhalb der Facette Thema verbindet die Themenanalyse Sicherheitsautomatisierung Artikel, die ein gemeinsames Thema, einen Signalfokus oder ein Monitoring-Thema teilen. Die Seite bietet den Lesern einen umfassenderen Zugang zu verwandter Berichterstattung, Quellenbelegen, Marktakteuren und Infrastrukturfolgen – mit ausreichend Kontext, um zu verstehen, warum das Thema für Unternehmensaktivitäten, Governance-Entscheidungen, regionale Risikoexposition und operationelle Risiken relevant ist. Leser können wiederkehrende Signale, betroffene Organisationen, öffentliche Belege, Marktkontext, Servicekontinuität, Beschaffung, Wettbewerb, Compliance und strategische Planungsfragen hinter dem Thema vergleichen, statt bei einer dünnen Liste passender Artikel stehenzubleiben. Es erklärt, was das Thema abdeckt, welche Infrastrukturakteure oder -politiken beteiligt sind, welche Belege die Berichterstattung stützen und warum das Thema für Betreiber, Kunden, Investoren und politisch interessierte Leser von Bedeutung sein kann.
Berichte
APNIC 62: Der Widerruf war veröffentlicht, die Browser entschieden verschieden
Ein Zertifikat stand auf der Sperrliste. Ob eine Verbindung deshalb endete, war eine andere Frage. Geoff Hustons Vorführung bei APNIC 62 macht die Grenze zwischen dem Eintrag einer Zertifizierungsstelle und der tatsächlichen Entscheidung eines Clients sichtbar.
Globale Cloud-Dienste-Trends
Coreros Umsatzsprung hat einen anderen Takt als das wiederkehrende Geschäft
Das erste Halbjahr zeigt echte operative Fortschritte. Es zeigt zugleich, wie stark Zeitpunkt und Art eines Softwarevertrags die veröffentlichten Wachstumsraten verschieben können.
IETF
IESG-Genehmigung ist noch kein Einsatz: Composite ML-KEM für CMS hängt weiter an einer offenen X.509-Kette
Am 18. September 2026 hat die IESG `draft-ietf-lamps-cms-composite-kem-03` in einer Protocol Action als Proposed Standard genehmigt. Das ist ein wichtiger Standardisierungsschritt, aber weder eine RFC-Veröffentlichung noch ein belastbarer Nachweis für Produktionsreife. Der…
IETF
Der Sammeltransport löst nicht die Frage, wer den Sicherheitsfall abschließt
Ein IETF-Entwurf soll mehrere Security Event Tokens in einem HTTPS-Aufruf befördern. Das spart Anfragen, verschiebt aber den entscheidenden Nachweis nicht: Eine Empfangsbestätigung ist kein Beleg dafür, dass ein Konto im anderen Verantwortungsbereich tatsächlich gesperrt wurde.
IETF
ACTN im Paket- und Glasfasernetz: Der Übergang braucht eine Fehlerordnung
Die Architektur kann den Weg eines Auftrags vom Koordinator zu Paket- und optischen Domänen beschreiben. Zwei Gutachten im IETF Last Call fragen nun nach dem schwierigen Rest: Wer erkennt auseinanderlaufende Zustände, wer stoppt weitere Eingriffe und wer übernimmt eine nur…
IETF
SAVNET im Last Call: Der Pfad ist noch kein Herkunftsbeweis
Ein vorhandener Rückweg zum Präfix sagt nicht automatisch, ob das Paket über den richtigen Nachbarn eingetroffen ist. Der IESG-Last-Call zu SAVNET prüft bis zum 1. Oktober, wie diese Lücke zwischen autonomen Systemen beschrieben und welche Anforderungen an künftige Lösungen…
Geschichte
Version 3 blieb, der Dienst änderte sich: RFC 2126s Kompatibilitätsschuld
Ein Byte blieb gleich, damit alte Implementierungen weiter sprechen konnten. Dafür brauchte jede neue Bedeutung einen eigenen Beleg. RFC 2126 machte aus äußerer Kontinuität eine innere Nachweispflicht.
Fallakte
RFC 9647: Die Beweiskette hinter Babel-Management mit YANG
Eine Babel-Routing-Tabelle kann eine Route als „selected“ ausweisen, während die technische Beweiskette dahinter noch Lücken hat: vom YANG-Datastore über die tatsächlich wirksame Interface-Policy, die authentifizierte Nachbarschaft, den installierten Forwarding-Zustand und die…
IETF
Die IESG prüfte Revision 12, die RFC-Produktion erhielt Revision 14
Safe-IOC trägt weiterhin denselben Namen, doch die geprüfte und die produzierte Fassung sind nicht dieselbe Datei. Nach dem Konflikturteil über Revision 12 folgten Revision 13 und 14 sowie getrennte Schritte von ISE, IANA und RFC Production Center. Erst eine nachvollziehbare…
Geschichte
Erst die Erlaubnis, dann der Anruf: RFC 2125 trennte die Belege
Ein Peer konnte einer zusätzlichen Leitung zustimmen, ohne dass bereits neue Bandbreite existierte. RFC 2125 hielt diesen Abstand fest: Die Antwort erlaubte den nächsten Schritt, eine spätere Call-Status-Nachricht berichtete erst das Ergebnis des wirklichen Anrufs.
Geschichte
Der FAS entschied – der Switch musste das Urteil erst umsetzen
RFC 2124 verlagerte die Zulassungspolitik in einen externen Dienst, ohne dessen Antwort mit dem späteren Verbindungszustand gleichzusetzen. LFAP trennte Entscheidung, Ausführung, Abgleich und Abrechnung in überprüfbare Übergaben.
IETF
BGP-SPF nach dem Neustart: Erreichbar heißt nicht freigegeben
Nach einem Kaltneustart kann der Soll-Ist-Vergleich zunächst beruhigend aussehen: Der Knoten ist wieder erreichbar, seine Präfixe antworten, doch der zuvor ausdrücklich signalisierte Nicht-Transit-Status fehlt. Genau darin liegt die operative Trennlinie. RFC 9815 behandelt das…
Trends bei Cloud-Diensten in Europa und dem Nahen Osten
PCI Pals £27,9 Mio. Contracted ARR sind noch kein testierter Umsatz
PCI Pal hob zwei operative Run-rate-Kennzahlen an und verschob zugleich die Veröffentlichung der FY26-Ergebnisse. Darin liegt kein Widerspruch: Vertragsabschluss, Bereitstellung, Umsatzrealisierung und Prüfungsabschluss folgen unterschiedlichen Zeitachsen.
Geschichte
Der Reset steckte im nächsten Paket: MPPC-Wiederanlauf nach RFC 2118
RFC 2118 gab Microsoft Point-to-Point Compression ein fortlaufendes Gedächtnis, das beide Endpunkte gemeinsam führen mussten. Ging unterwegs ein Paket verloren, forderte der Empfänger einen Reset an. Den neuen Dekodierbeginn lieferte jedoch das nächste mit `FLUSHED` markierte…
IETF
Vor dem Senden gehört der Entwurf nur seinem Autor: RFC 9787 und die kryptografische Bindungsgrenze
E-Mail-Sicherheit wird meist am fertigen Versandobjekt diskutiert. RFC 9787 lenkt den Blick auf einen früheren und operativ schwierigeren Zustand: den gespeicherten Entwurf. Solange eine Nachricht noch verändert werden kann, soll ihre Vertraulichkeit nicht vom entfernten…
Geschichte
Gleiche Zähler, begrenzte Aussage: Der Messvertrag von RFC 2108
RFC 2108 übernahm die Bedeutung zentraler Repeater-Zähler aus IEEE 802.3 und machte sie per SNMP vergleichbar. Das schuf eine gemeinsame Instrumentierung — aber weder eine automatische Ursachenanalyse noch einen Freibrief für Eingriffe.
IETF
NFFRR: Wer darf die zweite Rettung verbieten?
Fast Reroute ist dafür gebaut, Pakete trotz eines lokalen Ausfalls weiterzubringen. Genau diese Stärke kann bei einer zweiten Reparatur zur Schwäche werden: Zwei jeweils plausible lokale Entscheidungen können gemeinsam einen Loop erzeugen. RFC 9791 macht daraus einen…
Fallakte
RFC 9682: Reproduzierbar ist nicht automatisch richtig
Die Herkunft eines ausgelieferten Validators muss sich rückwärts prüfen lassen: Welcher Verbraucher hat ihn geladen, woraus wurde er erzeugt, welche semantische Darstellung wurde kompiliert? Die entscheidende Gegenprobe ist eine reproduzierbare Neuerzeugung mit exakt denselben…
Geschichte
Zwei Hash-Durchläufe machten den MAC wiederverwendbar, nicht die Vertrauensentscheidung: RFC 2104
RFC 2104 formte vorhandene iterative Hashfunktionen mit einem inneren und einem äußeren Schlüsseldurchlauf zu HMAC. Die Konstruktion blieb beim Austausch des Hashes erkennbar und nutzbar. Ein passendes Tag belegte jedoch nur eine eng umrissene Beziehung zwischen Schlüssel, Bytes…
IETF
Wenn ein SOLLTE zur falschen Gewissheit wird
Ein hypothetischer Konformitätstest meldet einen Fehler, weil eine Implementierung eine Registrierung ohne positive Link- oder Präfixprüfung akzeptiert. Der Prüfbericht erklärt, RFC 9686 verlange diese Prüfung ausnahmslos von jedem konformen Produkt. Genau darin liegt der Fehler…