Zusammenfassung

  • RFC 1087 war eine IAB-Policy-Erklärung in der historischen Umgebung eines von den USA getragenen Forschungsinternets, kein Protokoll zum Nachweis, zur Erkennung oder zur Sanktionierung von Handlungen.
  • RFC 1244 und RFC 2196 zeigen, dass eine handlungsfähige Nutzungsregel am Standort mit den Ressourcen entsteht: Dort müssen Eigentümer, Umfang, Verfahren, Mechanismen und Verantwortung zusammenkommen.

Eine zutreffende Norm entscheidet noch keinen Einzelfall

Der Einstieg von RFC 1087 beschreibt ein bestimmtes historisches Netz. Menschliche und wirtschaftliche Mittel der US-Regierung, der Industrie und der Wissenschaft hatten miteinander verbundene Netze hervorgebracht. Aus der Netzforschung war eine Infrastruktur für eine breitere Forschungsgemeinschaft geworden. Das IAB nennt sie eine nationale Einrichtung und verbindet ihren Nutzen mit Verfügbarkeit und Zugänglichkeit. In diesem Rahmen bezeichnet das Dokument Zugang und Nutzung als Privileg.

Darauf folgt eine Liste von fünf absichtlich begangenen Handlungen, die als unethisch und unzulässig gelten sollen: unberechtigten Zugang suchen, die beabsichtigte Nutzung stören, personelle, Kapazitäts- oder Rechenressourcen verschwenden, die Integrität rechnergestützter Informationen zerstören und die Privatsphäre von Nutzern beeinträchtigen. Diese Kategorien hatten Gewicht. Sie machten deutlich, dass eine vernetzte Forschungsinfrastruktur durch grenzüberschreitende Störungen ihren Wert verlieren konnte. Aus den Kategorien wurde jedoch kein Beweissystem.

„Unberechtigter Zugang“ beantwortet nicht, wem die betroffene Ressource gehörte, welche lokale Regel galt, welches Konto benutzt wurde oder ob eine Absicht nachgewiesen ist. „Störung“ ist weder ein Verfügbarkeitswert noch eine Ursachenanalyse oder eine Auswahl von Abhilfe. Auch die Erwähnung absichtlichen Handelns beweist noch keine Absicht. Dafür braucht es passende Aufzeichnungen, ein Untersuchungsverfahren und eine Instanz, die ihre Entscheidung verantwortet.

Hier liegen drei verschiedene Aufgaben. Eine Policy kann erklären, weshalb ein Sachverhalt Aufmerksamkeit verdient. Eine Kontrolle benötigt einen Umfang, einen verantwortlichen Betreiber, beobachtbare Eingaben und eine Entscheidungsregel. Eine Berechtigung benötigt einen Träger der Entscheidungsgewalt über die Ressource, die die Folge trifft. RFC 1087 stellte diese Ebenen nicht als gemeinsamen Dienst des Internets bereit. Er dokumentierte eine Policy in ihrem damaligen Kontext.

Die Mittel sollten erst gefunden und eingerichtet werden

Der Schlussteil von RFC 1087 ist folgerichtig zurückhaltend. Das IAB kündigte an, gemeinsam mit Bundesbehörden und anderen Interessierten technische und prozedurale Mechanismen zu identifizieren und einzurichten, die das Internet widerstandsfähiger gegen Störung machen sollten. Zugleich räumte es ein, dass Sicherheit teuer sein und den freien Informationsfluss hemmen könne.

Die Formulierung trennt das Problem von den Mitteln. Sie definiert weder Paketformat noch Identitätsnachweis, Sensor, Beweismaß, Sanktion oder Gerichtsbarkeit. Ebenso unterstellt sie nicht, dass alle Sites dieselben Eigentümer, Risiken oder Pflichten haben. Die Mechanismen mussten mit den jeweils zuständigen Parteien erst bestimmt und organisiert werden.

Nach einer klaren Regel werden ihr leicht imaginäre Werkzeuge zugeschrieben. Weil ein Verbot vernünftig klingt, scheint der Satz plötzlich auch Sensor, Mandat und Rechtsfolge zu enthalten. Doch eine veröffentlichte Policy wählt keinen Betreiber aus, prüft keine Fakten und bestimmt nicht, wie ein Fehlurteil korrigiert wird. Diese späteren Schritte haben eigene Verantwortlichkeiten und eigene Kosten.

Erst die Site verbindet Regel, Ressource und Verfahren

Das Site Security Handbook RFC 1244 von 1991 beschreibt die nächste Ebene konkret. Es nennt sich Leitfaden und Rahmen, nicht Kochbuch. Damit eine Policy wirksam ist, muss eine Site Entscheidungen treffen, Zustimmung gewinnen, die Policy kommunizieren und sie umsetzen. Als Site gilt eine Organisation mit Rechnern oder netzbezogenen Ressourcen; vorausgesetzt wird die Zustimmung und Unterstützung derjenigen, denen diese Ressourcen gehören.

Das ist mehr als Verwaltungswortschatz. Eine an einer Site geltende Acceptable-Use-Policy kann Konten, Systeme und Kommunikation abgrenzen. Sie kann Zugangs- und Autoritätsgrenzen, Reaktionsrollen und Verfahren benennen. Sie ist noch immer kein Paketmitschnitt und kein Incident-Beweis, aber sie verbindet eine Regel mit einer konkreten Ressource, einem verantwortlichen Akteur und einem umsetzbaren Umfeld.

RFC 2196 erläutert dieselbe Architektur später noch klarer. Als Informationsdokument verlangt er, dass eine Sicherheitspolitik Mechanismen benennt, mit denen ihre Anforderungen erfüllt werden. Eine Appropriate-Use-Policy kann festlegen, was Nutzer tun oder unterlassen sollen; sie soll Gesetze und Vorschriften berücksichtigen, vermittelt und überprüft werden. RFC 2504 ergänzt dies als Handbuch für Nutzer, ohne zu behaupten, ein Handbuch beweise die Erlaubnis eines einzelnen Standorts.

Die vier RFCs bilden keine dauerhafte Befehlskette. Sie zeigen eine Abfolge von Verantwortung. Eine allgemeine Erklärung benennt eine gemeinsame Gefahr. Der Betreiber lokaler Ressourcen übersetzt sie in Regeln, Verfahren und Mechanismen. Bevor ein einzelnes Ereignis als Verstoß gilt, werden weiterhin passende Belege benötigt. Die Überzeugungskraft des ersten Satzes lässt keinen dieser Schritte entfallen.

Was „zulässige Nutzung“ nicht feststellen kann

RFC 1087 bestimmt weder heutige Bedingungen eines Providers noch das anwendbare Recht, Eigentum an einem System oder die Berechtigung eines Nutzers. Er beweist nicht, dass ein bestimmtes Paket bösartig war, ein Ausfall absichtlich herbeigeführt wurde, Monitoring korrekt eingerichtet war oder eine Zwangsmaßnahme verhältnismäßig ausfiel. Er begründet keinen Vertrag, keine aktuelle Bereitstellung, keine Zuständigkeit und kein Betriebsergebnis.

Diese Begrenzung erhält Genauigkeit und Revidierbarkeit. Ein Netzinhaber kann seine Ressourcen bestimmen, relevante Belege sammeln und eine lokale Maßnahme ändern, wenn sich das Risiko verändert. Wer einen historischen Text behandelt, als habe er diese Entscheidungen bereits getroffen, presst Norm, Beweis, Eigentum und Ausführung in eine Behauptung. Weichen die Tatsachen ab, wird der Irrtum schwerer zu erkennen und zurückzunehmen.

Quellen und Beweisgrenze

Das eingefrorene Quellenpaket besteht aus RFC 1087, RFC 1244, RFC 2196 und RFC 2504. RFC 1087 belegt die IAB-Erklärung von 1989, die fünf Kategorien und den Verweis auf spätere technische und prozedurale Mechanismen. RFC 1244 und RFC 2196 stützen den Vergleich mit lokaler Policy, Mechanismen und Überprüfung; RFC 2504 den nutzerbezogenen Leitfaden. Keine Quelle belegt einen aktuellen Verstoß, eine Identität, eine Erlaubnis, ein Rechtsergebnis, Gerichtsbarkeit, Bereitstellung oder ein Betriebsergebnis.