Zusammenfassung

  • Der IDMEFv2-HTTPS-Entwurf empfiehlt 2xx erst, nachdem der Empfänger die Meldung sicher behandelt hat: durch dauerhafte Speicherung oder durch Übergabe an ein bestätigendes Folgesystem. Damit kann 204 No Content einen belastbaren Annahmebeleg darstellen.
  • Jede Meldung reist per eigenem POST. Revision 07 definiert aber weder Wiederholungsidempotenz noch Duplikatfenster oder endgültige Fallentscheidung. Dafür braucht das Bündnis ein Register aus Absenderidentität und verpflichtender Alert-ID.

Die unklare Lage entsteht nach erfolgreichem Schreiben

Ein Analyzer sendet eine Warnung. Der Manager schließt den Datenbank-Commit ab und beginnt, 204 zu senden. Bricht die Verbindung vor Empfang der Statuszeile ab, fehlen dem Analyzer die entscheidenden Bytes. Eine Wiederholung kann denselben Alarm zweimal korrelieren oder zwei Gegenmaßnahmen auslösen. Ohne Wiederholung könnte eine tatsächlich nicht gespeicherte Meldung verschwinden.

Transport of IDMEFv2 Messages over HTTPS ist ein individueller Internet-Draft vom 27. September 2026. Laut Datatracker besitzt er weder Stream noch formale Stellung im IETF-Standardisierungsprozess. Revision 07 strebt Standards Track an und würde RFC 4767 nur bei Annahme ablösen. Sie ist ein veränderlicher Vorschlag, kein Standard und kein Einsatznachweis.

Der exakte Text von Revision 07 verlangt eine IDMEFv2-Nachricht pro POST, erlaubt jedoch parallele Requests. Eine ungeeignete Nachricht führt zu 4xx; ein interner Verarbeitungsfehler des Empfängers zu 5xx. Vor allem dient der HTTP-Code als Quittung: 2xx soll erst nach Speicherung auf Platte oder in einer Datenbank beziehungsweise nach bestätigter Weiterleitung folgen.

Der 204 im Beispiel ist somit mehr als ein Zeichen erfolgreicher TLS-Übertragung. RFC 9110 beschreibt 204 allgemein als erfolgreiche Erfüllung ohne zusätzlichen Response-Inhalt. Der Entwurf ergänzt die anwendungsspezifische Zusage, welcher sichere Zustand dafür erreicht sein muss.

Eine UUID ersetzt keine Duplikatregel

Der zugehörige IDMEFv2-Datenmodellentwurf verlangt im Alert eine UUID als ID sowie CreateTime. Zusammen mit der Absenderidentität eignet sich das als stabiler Schlüssel. Der Transportentwurf bestimmt jedoch nicht, wie lange der Empfänger ihn behält, wie ein identischer zweiter Request beantwortet wird oder was dieselbe ID mit verändertem Payload bedeutet.

POST wird durch HTTP nicht idempotent. RFC 9110 rät von automatischer Wiederholung einer nicht idempotenten Methode ab, sofern der Client nicht die idempotente Anwendungssemantik kennt oder erkennt, dass der erste Versuch nie angewandt wurde. RFC 9205 verlangt deshalb von HTTP-basierten Protokollen eine explizite Anwendungssemantik.

Gegenseitige Authentisierung löst ein anderes Problem. Revision 07 verlangt X.509-Zertifikate beider Seiten, vollständige Pfadprüfung, DNS-IDs ohne Wildcards und eine ausdrückliche Liste zugelassener Peer-Zertifikate, gestützt auf RFC 5280 und RFC 6125. Das belegt, welcher berechtigte Teilnehmer sprach. Es belegt weder Wahrheit oder Einmaligkeit der Warnung noch deren Untersuchung und Abschluss.

Ein Konsortium sollte drei Nachweise trennen. Die Annahmequittung bindet Peer, Alert-ID, Payload-Hash und Persistierungszeit. Die Duplikatentscheidung hält Erst- und Letztsichtung, exakte Wiederholung oder widersprüchliche Wiederverwendung sowie die Reaktion fest. Die spätere Disposition dokumentiert Korrelation, Untersuchung, Eskalation, Verwerfung oder Abschluss. Dazu müssen die Mitglieder ihre eigenen SIEMs nicht aufgeben.

Running-Code Primacy verortet Beweise in der tatsächlich ausgeführten Kette von Empfang, Speicherung und Entscheidung. Minimum Initial Specification, Localized Future Decision trägt eine kleine gemeinsame Quittung bei lokaler Reaktionshoheit. On Authority, Belief, and the Internet’s Addressing System hält die Autoritäten auseinander: Zertifikat, HTTP-Quittung und Vorfallurteil stammen von verschiedenen Ausstellern.