Zusammenfassung

  • Die Weitergabebeschränkung eines IODEF-Elements kann aus seiner übergeordneten Struktur stammen. Ein untergeordnetes Element kann sie ausdrücklich verschärfen oder lockern.
  • Ein Auszug kann alle Sachangaben korrekt übernehmen und trotzdem den Zusammenhang verlieren, der ihren Empfängerkreis bestimmt.
  • Der ältere IODEF-Wert amber und das heutige TLP:AMBER bezeichnen nicht denselben Umfang. Ein Wechsel der Bezeichnung kann Kunden zusätzlich einbeziehen.

Bei der Abnahme eines Berichtsexports lässt sich die Vollständigkeit leicht falsch prüfen. Stimmen Name, Adresse und Zuständigkeit des übernommenen Kontakts, scheint die Übertragung gelungen. Schwerer zu sehen ist, ob die Bedingung für die Weitergabe mitgekommen ist. Stand sie nicht am Kontakt selbst, sondern eine Ebene darüber, kann der Auszug sachlich richtig und dennoch für die nächste Entscheidung unvollständig sein.

Dieser Fall ist ein Gedankenbeispiel, kein nachgewiesener Fehler eines Produkts. Er braucht weder manipulierte Adressen noch gebrochene Verschlüsselung. Es genügt, eine Information von der Beziehung zu lösen, aus der sie einen Teil ihrer Bedeutung erhält. Die Prüfung einzelner Werte erfasst diesen Verlust nicht unbedingt.

IODEF macht eine solche Abhängigkeit ausdrücklich darstellbar. RFC 7970 vom November 2016 definiert Version 2 des Informationsmodells für Sicherheitsvorfälle und Indikatoren samt XML-Datenmodell. Der aktuelle offizielle Eintrag führt das Dokument als Proposed Standard. Eine gemeinsame Darstellung erleichtert den Austausch, macht aber nicht jedes Feld zu einer eigenständig verständlichen Mitteilung. RFC 7970, offizieller Eintrag.

Nicht jede Vererbung führt zu mehr Einschränkung

Abschnitt 3.3.1 beschreibt restriction als Weitergabevorgabe des Absenders für eine Klasse und ihre untergeordneten Elemente. Ein Kind kann diese Vorgabe überschreiben. Dabei darf es sowohl eine strengere als auch eine weniger strenge Bedingung angeben. Fehlt eine lokale Angabe, wird der Wert des nächstgelegenen Vorfahren übernommen, der einen Wert festlegt. Die allgemeine Regel setzt für Incident den Standardwert private.

Ein ausdrücklich als private gekennzeichneter Incident kann deshalb einen ausdrücklich als public bezeichneten Contact enthalten. Damit lässt sich dieser Kontakt zur Weitergabe vorsehen, ohne den ganzen Vorgang freizugeben. Umgekehrt kann ein für Partner bestimmter Bericht einen privaten Kontakt enthalten. Die Beispiele erklären, was der Absender mit dem Format ausdrücken kann. Sie belegen nicht, dass er über sämtliche notwendigen Rechte zur Offenlegung verfügt. RFC 7970, Abschnitt 3.3.1.

Eine Oberfläche, die nur das oberste Kennzeichen zeigt, kann strengere Bedingungen im Inneren unterschlagen. Eine Oberfläche, die überall das strengste gefundene Kennzeichen anwendet, kann eine gewollte Ausnahme verdecken. Letzteres ist als bewusst gewählte konservative Hausregel denkbar. Es ist aber keine genaue Wiedergabe der Vorgaben für jedes einzelne Element.

Für die Zusammenarbeit kann gerade eine solche Ausnahme wertvoll sein. Ein anderer Netzbetreiber braucht womöglich nur die richtige Ansprechperson, nicht die sensiblen Einzelheiten des Vorfalls. Wird der Kontakt allein wegen der strengeren Umgebung zurückgehalten, entstehen Rückfragen oder die Gelegenheit zur Hilfe entfällt. Das ist ein möglicher Wirkungsmechanismus, keine hier gemessene Verzögerung. Er zeigt, weshalb pauschal strengere Behandlung nicht automatisch kostenfrei ist.

Ein fehlender Wert verweist anders als default

Man stelle sich nun einen Contact ohne eigenes restriction-Attribut innerhalb eines Incident mit partner vor. Der Kontakt erhält seine Vorgabe aus der übergeordneten Struktur. Ein Export, der diese Struktur nicht mitnimmt oder ihre Bedeutung anderweitig erhält, kann dem nächsten Leser die Grundlage für die Weitergabe nehmen. Dass alle Kontaktfelder identisch bleiben, beantwortet diese Frage nicht.

Ein ausdrücklich gesetztes default bedeutet etwas anderes als das Weglassen des Attributs. Es verweist auf eine Offenlegungsregel, die die kommunizierenden Parteien vorher vereinbart haben. Im ersten Fall muss also ein Vorfahr gefunden werden, im zweiten eine Vereinbarung. Beide Fälle auf die Standardeinstellung der empfangenden Anwendung abzubilden, kann eine dritte, ursprünglich nicht gemeinte Regel einführen. IANA-Register Restriction.

Dabei sollte man die Klarheit der allgemeinen Regel nicht auf jede Einzelbeschreibung überdehnen. Einige klassenbezogene Angaben zu Standardwerten müssen sorgfältig mit dem allgemeinen Text und dem Schema abgeglichen werden. Dieser Beitrag verwendet deshalb Contact und ausdrückliche Attribute. Er behandelt ausgelassene Angaben bei EventData oder Expectation nicht als zweifelsfrei geklärte Beispiele. Ein Austauschprofil kann eine gemeinsame Handhabung dokumentieren, ohne zu behaupten, damit alle Textfragen des RFC offiziell gelöst zu haben.

Das vertraute Farbetikett kann einen anderen Kreis meinen

Auch der Stand des verwendeten Vokabulars gehört zum Kontext. Im überprüften IANA-Register bleiben die älteren IODEF-Aliase erhalten: white entspricht public, green entspricht partner, amber entspricht need-to-know und red entspricht private. Die Bedeutung von need-to-know ist dort auf Personen innerhalb der Organisation beschränkt, die die Information benötigen. IANA.

FIRST verwendet im aktuellen TLP 2.0, das seit August 2022 maßgeblich ist, an der entscheidenden Stelle eine andere Grenze. TLP:AMBER erlaubt die erforderliche Weitergabe innerhalb der Empfängerorganisation und an deren Kunden, um Organisation und Kunden zu schützen und weiteren Schaden zu vermeiden. TLP:AMBER+STRICT begrenzt sie auf die Organisation. Die Quelle kann zusätzliche Bedingungen festlegen; eine weitere Verbreitung erfordert ihre ausdrückliche Erlaubnis. Die Kennzeichnungen bleiben auch in einem deutschen Text unverändert. FIRST TLP 2.0.

Aus diesem Vergleich folgt: Die automatische Ersetzung von IODEF-amber durch ein unqualifiziertes TLP:AMBER kann Kunden zu einem zuvor organisationsinternen Kreis hinzufügen. Das ist eine Schlussfolgerung aus veröffentlichten Definitionen, kein Nachweis einer tatsächlich erfolgten Offenlegung. Ebenso wenig ist damit eine allgemein anerkannte Übersetzungstabelle festgelegt. Zusätzliche Vorgaben und die genaue Organisationsgrenze müssen weiterhin berücksichtigt werden.

Die Stelle, an der diese Zuordnung gepflegt wird, ist daher mehr als eine Formatfrage. Wer sie ändert, kann die Bedeutung der Weitergabevorgabe ändern, ohne eine einzige konkrete Empfängeradresse anzufassen. Das Betriebsteam und der Verantwortliche für das Austauschprofil müssen denselben Vorgang sehen können: nicht nur eine technische Anpassung, sondern gegebenenfalls eine Entscheidung über den zulässigen Adressatenkreis.

Schema-Konformität ersetzt kein gemeinsames Verständnis

RFC 7970 trennt die Wohlgeformtheit von XML von einer umfassenden semantischen Prüfung. Abschnitt 4.3 verlangt wohlgeformtes XML, empfiehlt die Einhaltung des Schemas und fordert, die zusätzlichen Einschränkungen des Informationsmodells einzubeziehen. Ein erfolgreich eingelesener Bericht beweist deshalb noch nicht, dass seine operativen Bedingungen verstanden wurden.

Das im November 2018 bestätigte technische Erratum 5543 liefert ein begrenztes Beispiel. Es korrigiert das Schema für Confidence, damit der im Text vorgesehene numerische Inhalt darstellbar ist. Damit wird eine Inkonsistenz der Darstellung behoben, nicht die Bedeutung der Zahlen vereinheitlicht. Die numerische Interpretation bleibt außerhalb der Definition des RFC. Das Erratum entscheidet außerdem nicht über Standardwerte von restriction. Erratum 5543, RFC 7970.

Diese Unterscheidung hat einen praktischen Nutzen. Ein Syntaxfehler, eine unklare normative Passage und eine nicht auffindbare Vereinbarung brauchen unterschiedliche Antworten. Wer alles unter fehlerhaften Eingangsdaten verbucht, erhält eine einfache Statistik, aber noch keine brauchbare Zuständigkeit.

Die Bedingungen gelten über die Zustellung hinaus

IODEF verlangt Vertraulichkeit, Integrität und Authentizität vom zugrunde liegenden Austausch. Gleichzeitig enthält die Weitergabevorgabe selbst keine technische Garantie, dass der Empfänger sie einhält. Die Datenschutzbetrachtung erfasst auch gespeicherte Berichte, abgeleitete Analysen und Angaben über Dritte. Wiederholte Übermittlungen können durch die Verknüpfung von Kennungen zusätzliche Erkenntnisse ermöglichen. RFC 7970, Abschnitt 9.

RFC 6545 zu RID betrachtet Datenschutzvereinbarungen und Austauschprofile unter anderem danach, welche Daten weitergegeben werden, wie sie geschützt sind und wie weit sie gelangen dürfen. Ein Ergebnis kann eine Abhilfemaßnahme bestätigen, ohne die Identität der Angriffsquelle offenzulegen. Zusammenarbeit verlangt also nicht grundsätzlich die größtmögliche Offenlegung. Schutz auf einzelnen Transportabschnitten entscheidet zudem nicht allein über die Sichtbarkeit entlang der gesamten Verbindungskette. Diese Ausführungen betreffen Protokolldesign, nicht eine heutige rechtliche Erlaubnis für einen bestimmten Austausch. RFC 6545, Abschnitte 9.5–9.6.

Daraus ergibt sich ein hier vorgeschlagener betrieblicher Ansatz: den Auszug als eigene Ausgabe prüfen. Die wirksame Beschränkung, ihre Herkunft und die einschlägige Vereinbarung beziehungsweise Vokabularversion müssen erklärbar bleiben. Dafür schreibt dieser Beitrag weder dem RFC ein bestimmtes Protokollierungsformat zu noch empfiehlt er, sensible Originalberichte überall zu vervielfältigen. Er fordert genügend Zusammenhang, um die Entscheidung nachvollziehen zu können.

Lu Heng unterscheidet zwischen symbolischer Beschreibung und wirksamer Verfügungsmacht. Auf diesen Fall begrenzt angewandt, lenkt das den Blick auf die Stelle, an der eine Kennzeichnung praktisch umgesetzt wird: Export, Empfängerfreigabe und Umgang beim Empfänger. Sein Essay handelt nicht von IODEF. Er dient hier als analytische Perspektive, nicht als Urteil über das Protokoll oder als rechtliche Grundlage. Lu Heng über Wirklichkeitsebenen.

Ein Auszug darf das Unnötige weglassen. Die Erklärung, warum der verbleibende Inhalt weitergegeben werden darf, gehört nicht zum Unnötigen.